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

On Wed, Dec 05, 2007 at 02:19:58PM -0800, Junio C Hamano wrote:

quoted

what rewriting was done by the server, and if another push happened in
the meantime, the client will have to basically guess about which
commits correspond to the ones it pushed.

Ok, but the output from fetch is meant to be human readable and we do
not promise parsability, so if we go this route (which I think you made
a sensible argument for) we would need a hook on the pushing end to act
on this (perhaps record the correspondence of pushed and rewritten sha1
somewhere for the hook's own use).

I am not clear on what you mean. Are you saying that the send-pack code
should _not_ recognize the "ok, but I rewrote your commit" status?
Because that is how we will avoid updating the tracking ref, which I
think is a good goal.

Or are you saying "it's ok to understand the 'ok, but...' response and
not update the tracking ref, but pulling the new hash from the message
is up to a hook on the pushing side"? Which I think it reasonable.

Or alternatively, "there should be a hook on the pushing side which is
allowed to set the ref status to 'ok, but don't bother updating the
tracking ref' or 'ok, but here is the actual thing to put in the
tracking ref'"? Which is also fine by me.

-Peff