Reason is that although the first entry in the line is "(delete)", the
check occurs on the result which only includes the SHAs; this is actually
all zeroes in the delete case. This was silently failing before we
error checked more rigorously.
Go 1.5 is genuinely parallel and we cannot guarantee that the transfer
channel from TransferQueue is fully read from before q.Wait() returns;
they can be parallel. Instead use our own sync channel on the closing
of the transfer channel.
this change improves drastically pre-push behaviour, by not sending
lfs objects which are already on a remote. Works perfectly with
pushing new branches and tags.
currently pre-push command analyse "local sha1" vs "remote sha1" of the
ref being pushed and if "remote sha1" is available locally tries to send
only lfs objects introduced with new commits.
why this is broken:
- remote branch might have moved forward (local repo is not up to date).
In this case you have no chance to isolate new lfs objects ("remote sha1"
does not exist locally) and git-lfs sends everything from the local
branch history.
- remote branch does not exist (or new tag is pushed). Same consequences.
But what is important - local repository always have remote references,
from which user created his local branch and started making some local
changes. So, all we have to do is to identify new lfs objects which do
not exist on remote references. And all this can be easily achieved with
the same all mighty git rev-list command.
This change makes git-lfs usable with gerrit, where changes are uploaded
by using magic gerrit branches which does not really exist. i.e.
git push origin master:refs/for/master
in this case "refs/for/master" does not exist and git feeds all 0-s as
"remote sha1".
Renamed Checkable to DownloadCheckable because it only applies to download,
upload checks differently and uses different struct fields. Incorporated
with download_queue.go since code is now smaller & common.
In batch mode you don't get an error from a missing Check(), you just get
a lack of download link (get an upload link instead). Therefore the only
reliable way to judge whether Check() worked is to check the transfer chan.
Also add tests for batch mode to prove this works
Go back to requiring a count and size up front, but better track and
display files that are skipped because they don't need to transfer. This
makes it easier to judge what is happening based on the progress output.
This removes the `pb` based progress bar for the transfer queue and add
a simpler custom bar. pb really wants to know total counts and byte
sizes up front but when doing batches of n we would prefer to not know
that. This is due to the fact that the batcher will block until it is
drained instead of processing all pointers and storing them in memory
while transfer operations run. This also clarifies when files are
skipped because the server already has them. Progress output here
contains the number of finished transfers/bytes, the number of
transfers/bytes currently in the queue, and the number of files skipped,
if any.
