Re: Proposal: branch.<name>.remotepush

Michael J Gruber [off-list ref] writes:

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

quoted

Jonathan Nieder [off-list ref] writes:

quoted

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

Junio C Hamano wrote:

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

A "push" should never touch remote/refs/origin/* if there is a pushurl
configured.  Otherwise, it should.  I want my push to affect my
status.  The configuration variable makes no sense and should not
exist.

Unfortunately, pushurl doesn't get the same privileges as url even
though they're equal remotes.  How is my fork "inferior" to the
upstream project in any way?  A lot of us might be working on this
fork, and we will need something corresponding to refs/remotes/* to
inspect its state.  Like I said earlier, I think pushurl has a very
limited usecase: when the two URLs are actually mirrors (there is
really no fork; we're back in a centralized environment).  In fact, I
think it should be deprecated, because it interferes with my more
general approach.

Let's see what happens if we have two actual remotes.
remote/refs/origin/* will be updated when I fetch from, and push to,
origin.   remote/refs/ram/* will be updated when I fetch from, and
push to, ram.  It's very simple, and I don't need this complex rule of
when to update refs.  We should have a way to pair remotes together as
upstream/ downstream in the future.  Maybe even have a hierarchy of
remotes.