Re: Proposal: branch.<name>.remotepush

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 8, 2013, 17:16 UTC
Message-ID: <7vobfu3ev3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

Show 23 quoted lines

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

Fixing that misfeature to always pretend it immediately turned around and fetched may have a different benefit, too.

A straightforward and simple solution to Ram's original problem may be to define pushurl to point at his publishing repository after all, and teach "git push" not to pretend it immediately fetched with the same "fix".

	[remote "origin"]
        	url = ... where Ram fetches and pulls from ...
                pushurl = ... where Ram pushes to ...
                fetch = refs/heads/*:refs/remotes/*
		updateTrackOnPush = no

Then "git fetch" (or "git pull") will update the remote tracking branches Ram fetches from, and once his topic is finished, he can push to his publishing location, which won't touch the remote tracking branches used to keep track of the place he fetches from.