{"thread":{"id":"43243","subject":"Re: Push and remote refs","startedAt":"2006-11-05T18:50:11Z","lastAt":"2006-11-05T21:50:00Z","messageCount":5,"participants":["Jeff King","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298522","messageId":"Pine.LNX.4.64.0611051333210.9789@iabervon.org","threadId":"43243","inReplyTo":null,"subject":"Push and remote refs","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-11-05T18:50:11Z","receivedAt":"2006-11-05T18:50:11Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"My current workflow as maintainer of a couple of projects is:\n\nI have a publicly-accessible repository, whose master is the important \nbranch. When there are changes that I want to add, I fetch this branch on \na workstation to the workstation's \"mainline\" branch, pull into \n\"for-mainline\" (which is a fast-forward), apply patches, test, commit, and \npush back to master.\n\nUsually, I use the same computer to do this multiple times in a row, and \nit's a bit inconvenient that, after pushing local \"for-mainline\" to remote \n\"master\", I have to fetch remote \"master\" to local \"mainline\". It would be \nnice if git would update local tracking of remote refs when it pushes to \nthose remote refs.\n\n(Furthermore, I'm also using another branch to do development, by being a \nlot less careful about the quality of commits in it, and generating \npatches out of the diff between the development branch and mainline. But I \ndo development on multiple workstations, so I have a remote branch on my \nserver that I push the development work to, so that I can get it from \nother computers even before I clean it up and put it in the mainline. When \nI'm generating patches, I'm doing it between \"for-mainline\" and the \ntracking branch for the remote development, which means that I remember to \npush my development to the server. But then I have to fetch it back \nimmediately so that I can use it to generate patches.)\n\nI can't think of a situation in which you would want to not get the effect \nof an immediate fetch after a successful push, and it saves a couple of \nssh connections to use the local knowledge that, at least for an instant, \nthe remote ref matches the local one. Is there some reason not to do this?\n\n\t-Daniel\n"},{"id":"298703","messageId":"7vhcxdu1ln.fsf@assigned-by-dhcp.cox.net","threadId":"43243","inReplyTo":"Pine.LNX.4.64.0611051333210.9789@iabervon.org","subject":"Re: Push and remote refs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-05T19:37:08Z","receivedAt":"2006-11-05T19:37:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> Usually, I use the same computer to do this multiple times in a row, and \n> it's a bit inconvenient that, after pushing local \"for-mainline\" to remote \n> \"master\", I have to fetch remote \"master\" to local \"mainline\". It would be \n> nice if git would update local tracking of remote refs when it pushes to \n> those remote refs.\n\nI recall discussing this exact behaviour with Pasky when he\nadded it to Cogito.  I think we concluded that it is a very\nsensible thing to pretend we fetched immediately after we\nsuccessfully pushed and got the same thing back, and there is no\nrisk of data loss or user confusion, as long as we catch failure\nfrom the push and refrain from doing this update, which Cogito\ndid implement correctly when we discussed this.\n\n\n"},{"id":"294123","messageId":"20061105210607.GA28320@coredump.intra.peff.net","threadId":"43243","inReplyTo":"7vhcxdu1ln.fsf@assigned-by-dhcp.cox.net","subject":"Re: Push and remote refs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-11-05T21:06:07Z","receivedAt":"2006-11-05T21:06:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 05, 2006 at 11:37:08AM -0800, Junio C Hamano wrote:\n\n> I recall discussing this exact behaviour with Pasky when he\n> added it to Cogito.  I think we concluded that it is a very\n> sensible thing to pretend we fetched immediately after we\n> successfully pushed and got the same thing back, and there is no\n> risk of data loss or user confusion, as long as we catch failure\n> from the push and refrain from doing this update, which Cogito\n> did implement correctly when we discussed this.\n\nIs it possible for hooks on the receiving side to change the tip commit\nin some way? For example, the 'update' hook could do some markup on the\ncommit message or contents, creating a new commit and using it instead\nof the pushed one; in this case, the sending side ends up with an\nincorrect (and unrelated) SHA1. Is this simply too insane to worry\nabout?\n\n"},{"id":"298083","messageId":"7vveltoa0l.fsf@assigned-by-dhcp.cox.net","threadId":"43243","inReplyTo":"20061105210607.GA28320@coredump.intra.peff.net","subject":"Re: Push and remote refs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-05T21:31:54Z","receivedAt":"2006-11-05T21:31:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sun, Nov 05, 2006 at 11:37:08AM -0800, Junio C Hamano wrote:\n>\n>> I recall discussing this exact behaviour with Pasky when he\n>> added it to Cogito.  I think we concluded that it is a very\n>> sensible thing to pretend we fetched immediately after we\n>> successfully pushed and got the same thing back, and there is no\n>> risk of data loss or user confusion, as long as we catch failure\n>> from the push and refrain from doing this update, which Cogito\n>> did implement correctly when we discussed this.\n>\n> Is it possible for hooks on the receiving side to change the tip commit\n> in some way? For example, the 'update' hook could do some markup on the\n> commit message or contents, creating a new commit and using it instead\n> of the pushed one; in this case, the sending side ends up with an\n> incorrect (and unrelated) SHA1. Is this simply too insane to worry\n> about?\n\nI do not think it is sane for the update hook to muck with tips\nin any way (they are meant for making policy decision whether to\nallow the push -- we do not enforce this, partly because the\nmajorly lockless nature of git makes it impossible to, but then\nupdate hook is free to invoke \"rm -rf $GIT_DIR\" and nobody\nprevents it from doing so.  It is the same kind of user shooting\nat his foot).\n\nThe post-update hook is free to do anything what it wants.  But\nthat does not make the Cogito's \"pretend we have fetched\nimmediately after we pushed\" semantics invalid.  If the\npost-update hook rewinds the tip we just pushed, it is the same\nthing as in the case where the post-update hook did not do\nanything but somebody else, a human user, did the equivalent\nrewinding of the branch, and the pretended fetch happened\nbetween the time the push successfull finished and the time that\nsomebody else did the rewinding, so this is nothing new.  The\nnext push would notice that the tip does not fast forward in\neither case.\n"},{"id":"296931","messageId":"20061105214959.GA28728@coredump.intra.peff.net","threadId":"43243","inReplyTo":"7vveltoa0l.fsf@assigned-by-dhcp.cox.net","subject":"Re: Push and remote refs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-11-05T21:50:00Z","receivedAt":"2006-11-05T21:50:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 05, 2006 at 01:31:54PM -0800, Junio C Hamano wrote:\n\n> post-update hook rewinds the tip we just pushed, it is the same\n> thing as in the case where the post-update hook did not do\n> anything but somebody else, a human user, did the equivalent\n> rewinding of the branch, and the pretended fetch happened\n\nYes, I think this is a sensible way of looking at it. I withdraw my\nquestion. :)\n\n"}]}