Re: Push and remote refs

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

Daniel Barkalow <barkalow@iabervon.org> writes:

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:

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?

Jeff King <peff@peff.net> writes:

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.

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

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