Push and remote refs

Push and remote refs

[Daniel Barkalow]

My current workflow as maintainer of a couple of projects is:

I have a publicly-accessible repository, whose master is the important 
branch. When there are changes that I want to add, I fetch this branch on 
a workstation to the workstation's "mainline" branch, pull into 
"for-mainline" (which is a fast-forward), apply patches, test, commit, and 
push back to master.

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.

(Furthermore, I'm also using another branch to do development, by being a 
lot less careful about the quality of commits in it, and generating 
patches out of the diff between the development branch and mainline. But I 
do development on multiple workstations, so I have a remote branch on my 
server that I push the development work to, so that I can get it from 
other computers even before I clean it up and put it in the mainline. When 
I'm generating patches, I'm doing it between "for-mainline" and the 
tracking branch for the remote development, which means that I remember to 
push my development to the server. But then I have to fetch it back 
immediately so that I can use it to generate patches.)

I can't think of a situation in which you would want to not get the effect 
of an immediate fetch after a successful push, and it saves a couple of 
ssh connections to use the local knowledge that, at least for an instant, 
the remote ref matches the local one. Is there some reason not to do this?

	-Daniel

Re: Push and remote refs

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> 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.

Re: Push and remote refs

[Jeff King]

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?

Re: Push and remote refs

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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?

I do not think it is sane for the update hook to muck with tips
in any way (they are meant for making policy decision whether to
allow the push -- we do not enforce this, partly because the
majorly lockless nature of git makes it impossible to, but then
update hook is free to invoke "rm -rf $GIT_DIR" and nobody
prevents it from doing so.  It is the same kind of user shooting
at his foot).

The post-update hook is free to do anything what it wants.  But
that does not make the Cogito's "pretend we have fetched
immediately after we pushed" semantics invalid.  If the
post-update hook rewinds the tip we just pushed, it is the same
thing as in the case where the post-update hook did not do
anything but somebody else, a human user, did the equivalent
rewinding of the branch, and the pretended fetch happened
between the time the push successfull finished and the time that
somebody else did the rewinding, so this is nothing new.  The
next push would notice that the tip does not fast forward in
either case.

Re: Push and remote refs

[Jeff King]

On Sun, Nov 05, 2006 at 01:31:54PM -0800, Junio C Hamano wrote:

> post-update hook rewinds the tip we just pushed, it is the same
> thing as in the case where the post-update hook did not do
> anything but somebody else, a human user, did the equivalent
> rewinding of the branch, and the pretended fetch happened

Yes, I think this is a sensible way of looking at it. I withdraw my
question. :)