On Sun, May 06, 2012 at 07:10:17PM -0400, Seth Robertson wrote: > The output of fetch seems to do that, quite nicely. > > ---------------------------------------------------------------------- > > git fetch > remote: Counting objects: 24155, done. > remote: Compressing objects: 100% (6651/6651), done. > remote: Total 21446 (delta 15831), reused 20146 (delta 14640) > Receiving objects: 100% (21446/21446), 6.78 MiB | 239 KiB/s, done. > Resolving deltas: 100% (15831/15831), completed with 574 local objects. > From git://git.kernel.org/pub/scm/git/git > ea2c69e..edf1412 maint -> origin/maint > ae4479d..8275905 master -> origin/master > + b6b16ad...8a79d96 next -> origin/next (forced update) > + 47db9a0...30b8c95 pu -> origin/pu (forced update) > ce29fc8..3ca5cbc todo -> origin/todo > ---------------------------------------------------------------------- This output is human-consumable, and is not guaranteed to remain stable in future versions of git. Push has a --porcelain mode for this reason, but nobody has bothered to implement it for fetch. > If you care about race conditions (and really, a lockfile(1) call can > take care of that easily enough), then parse the output of fetch which > will make it clear what *this* call did. Custom locking is not sufficient, as a push could modify refs behind your back. I guess you could get by with a pre-receive hook that also took the lock. But that is unnecessarily crappy; git does not have a whole repo lock, and there is no need for lock contention between pushes and fetches that are touching different refs. I would say the "most git" thing would be to implement "fetch --porcelain", and use its output. -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