On Wed, Dec 05, 2007 at 02:19:58PM -0800, Junio C Hamano wrote: > > 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 - 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
