Re: post-fetch, tweak-fetch hook

From: Jeff King <peff@peff.net>
Date: May 7, 2012, 07:29 UTC
Message-ID: <20120507072934.GC19874@sigill.intra.peff.net>
In-Reply-To: <201205062310.q46NAHnM022630@no.baka.org>

On Sun, May 06, 2012 at 07:10:17PM -0400, Seth Robertson wrote:

Show 16 quoted lines

> 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