Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > On Dec 2, 2007, at 6:16 PM, Junio C Hamano wrote: >>> ..., but an >>> "ok, but btw I changed your commit" status from receive-pack seems >>> like >>> it would be useful, for two reasons: >> Sensible argument. I stand corrected. > > If we want that status in principle, I'd argue that sending down the > updated commit SHA1 is actually the right way to indicate it, because > it gives the client all the information it needs to make an > intelligent choice about what to do next. If you don't transmit the > modified SHA1, the client will have to do another fetch to find out > 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). - 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
