Re: Push and remote refs

Daniel Barkalow [off-list ref] writes:

Usually, I use the same computer to do this multiple times in a row, and 
it's a bit inconvenient that, after pushing local "for-mainline" to remote 
"master", I have to fetch remote "master" to local "mainline". It would be 
nice if git would update local tracking of remote refs when it pushes to 
those remote refs.

I recall discussing this exact behaviour with Pasky when he
added it to Cogito.  I think we concluded that it is a very
sensible thing to pretend we fetched immediately after we
successfully pushed and got the same thing back, and there is no
risk of data loss or user confusion, as long as we catch failure
from the push and refrain from doing this update, which Cogito
did implement correctly when we discussed this.

On Sun, Nov 05, 2006 at 11:37:08AM -0800, Junio C Hamano wrote:

I recall discussing this exact behaviour with Pasky when he
added it to Cogito.  I think we concluded that it is a very
sensible thing to pretend we fetched immediately after we
successfully pushed and got the same thing back, and there is no
risk of data loss or user confusion, as long as we catch failure
from the push and refrain from doing this update, which Cogito
did implement correctly when we discussed this.

Is it possible for hooks on the receiving side to change the tip commit
in some way? For example, the 'update' hook could do some markup on the
commit message or contents, creating a new commit and using it instead
of the pushed one; in this case, the sending side ends up with an
incorrect (and unrelated) SHA1. Is this simply too insane to worry
about?