Michael J Gruber wrote: > Junio C Hamano venit, vidit, dixit 08.02.2013 09:16: >> Jonathan Nieder <jrnie...@gmail.com> writes:
>>> "Wait, why did the remote rewind?" >> >> Oh, I am very well aware of that glitch. >> >> "git push" has this hack to pretend as if the pusher immediately >> turned around and fetched from the remote. >> >> It shouldn't have been made to do so unconditionally; instead it >> should have been designed to give the pushee a way to optionally >> tell you "I acccept this push, but you may not see it to be updated >> to that exact value you pushed when you fetched from me right now". Yes, I agree with this. The "git push" hack does seem to be useful in practice for helping people just starting to use git. If they have a separate "gitk --all" window open, they can refresh it and see the remote-tracking branch corresponding to the branch that has been pushed advancing. It matches a model in which remote-tracking refs represent "git's idea of where these branches are in the remote repository". And in that model, a remote being able to respond to a push with "ref update queued, but please keep in mind that it may take me a while to chew through that queue" should be perfectly reasonable. [...] > And this seems to be more natural, too. It can keep the internals (the > auxiliary ref on the server side) hidden from the user. Just to clarify: this is not an internal ref being exposed. No auxiliary refs/for/master ref actually exists. The ref Gerrit users push to is a UI fiction. That's important because otherwise two developers could not propose changes for the same branch at the same time. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
