Re: How can I tell if anything was fetched?

[Jeff King <peff@peff.net>]

On Thu, Oct 11, 2012 at 06:45:09PM +0200, Andreas Schwab wrote:

> Phil Lawrence <prlawrence@gmail.com> writes:
> 
> > One approach might be to first generate a state-of-the-repo SHA1:
> >     # http://stackoverflow.com/a/7350019/834039
> >     # http://git-scm.com/book/ch9-2.html
> >     {
> >         git rev-list --objects --all
> >         git rev-list --objects -g --no-walk --all
> >         git rev-list --objects --no-walk \
> >             $(git fsck --unreachable |
> >               grep '^unreachable commit' |
> >               cut -d' ' -f3)
> >     } | sort | uniq | git hash-object -w --stdin
> 
> I think you'd only need to record the state of all refs (eg. the output
> of `git for-each-ref') to reliably detect any changes.

To clarify on the "only" in your sentence: it is not just that recording
the ref changes is more efficient. But recording the object state is
actively wrong. You might have fetched ref changes that do not introduce
new objects (e.g., a rewind of history, or a branch deletion). The
before-and-after ref state is both sufficient and necessary.  I suspect
you already realized that, Andreas, but I wanted to make sure it was
clear to readers, including the OP.

Checking ref state does suffer from potential race conditions with any
other simultaneous updates.  I don't think there is any reason we
couldn't have "git fetch" produce a machine-readable output detailing
what happened. We already have the same for "git push". I think it is
simply the case that nobody has really wanted it so far.

-Peff