On Thu, Oct 11, 2012 at 06:45:09PM +0200, Andreas Schwab wrote: > Phil Lawrence <prlawrence@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html