Re: [PATCH v4] Allow update hooks to update refs on their own.

From: Jeff King <peff@peff.net>
Date: Dec 3, 2007, 02:13 UTC
Message-ID: <20071203021333.GC8322@coredump.intra.peff.net>
In-Reply-To: <20071202212224.GA22117@midwinter.com>

On Sun, Dec 02, 2007 at 01:22:24PM -0800, Steven Grimm wrote:

Show 7 quoted lines

> 	Since Junio's main objection to this seemed to be the protocol
> 	change to bypass the automatic update of the tracking ref in
> 	git-send-pack, that code is gone (thus reverting this to the
> 	same code change as the initial version!) and I added a section
> 	to the git-send-pack manual page describing the automatic
> 	tracking ref update behavior, which wasn't documented at all
> 	before. Someone please review my terminology there.

I am dubious of the usefulness of passing back the new commit id, but an "ok, but btw I changed your commit" status from receive-pack seems like it would be useful, for two reasons:

  - it can be displayed differently, so the user is reminded to do a
    fetch afterwards
  - we can avoid updating the tracking ref, which makes it less likely
    to result in a non-fast forward fetch next time.  For example,
    consider:

      1. The remote master and my origin/master are at A.
      2. I make a commit B on top of A.
      3. I push B to remote, who rewrites it to B' on top of A. At the
         same time, I move my origin/master to B.
      4. I fetch, and get non-ff going from B to B'.

    If I had never written anything to my origin/master, it would be a
    fast forward. And obviously git handles it just fine, but it is more
    useful to the user during the next fetch to see A..B rather than
    B'...B.

-Peff