Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html