Re: Proposal: branch.<name>.remotepush

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Feb 8, 2013, 10:38 UTC
Message-ID: <5114D5B0.5080906@drmicha.warpmail.net>
In-Reply-To: <7v622343uy.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:

Show 19 quoted lines

> 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".
> 
> The hack is not my design; it was not even something I accepted
> without complaints, so I can badmouth about it all I want without
> hesitation ;-)
> 
> More importantly, we could fix it if we wanted to.

And this seems to be more natural, too. It can keep the internals (the auxiliary ref on the server side) hidden from the user.

As for the triangle remote, I really think we should clean up the situation regarding push, pushurlinsteadof and the various different and inconclusive output formats of "git remote" (with or without "-v", with or without a remote name) first, before introducing yet another way to twist things around. "git push downstream" does not hurt any kittens (while git remote ouput does, somehwat).

Michael