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