Re: Proposal: branch.<name>.remotepush

[Jonathan Nieder <jrnieder@gmail.com>]

Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@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