Re: Proposal: branch.<name>.remotepush

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 8, 2013, 18:36 UTC
Message-ID: <20130208183629.GA8461@google.com>
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>

Michael J Gruber wrote:

> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@gmail.com> writes:

Show 11 quoted lines

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