Re: [PATCH] push: Alias pushurl from push rewrites

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 29, 2013, 05:29 UTC
Message-ID: <7v8v56rcxc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130328235319.299cb494@hoelz.ro>

Rob Hoelz <rob@hoelz.ro> writes:

> Honestly, if my workflow here is stupid and not "Git-like" and someone
> has a better suggestion, I would happy to let my patch go.  Using two
> remotes is an option, but to me, using this triangular setup is just
> easier.

I think you are conflating two unrelated things.

Pulling from one repository to integrate others' work with yours (either by merging others' work to yours, or rebasing your work on others'), and pushing the result of your work to another repository to publish, i.e. triangular workflow, is no less "Git-like" than pulling from and pushing to the same repository. Both are valid workflows, and Git supports them.

What is not correct in your set-up is that a single remote with URL and pushURL (or rewritten URL derived from them via pushInsteadOf and insteadOf) that point at two different repositories is *not* the way to express that triangular configuration. You name two remotes, pull from one and push to the other.

If you look at Ram's "triangular workflows" series, cf.

    http://thread.gmane.org/gmane.comp.version-control.git/219387

you can see that a progress is being made to make the "two remotes" configuration easier to use.

The discussion on the earliest iteration of the patch series, cf.

    http://thread.gmane.org/gmane.comp.version-control.git/215702

shows that even I initially made the same "pointing two different repositories with URL and pushURL should be sufficient" mistake, which was corrected by others. The primary issue is "remote tracking branches are designed to keep track of the state of the branches at the named remote"---for this reason alone, you must not name a logically different repository with URL and pushURL for a single remote.

So that is one thing. tl;dr: Triangular workflow is valid. A single remote with URL and pushURL to point at the two remote repositories is not a valid way to express that workflow.

The other thing is if it is worth risking to break the backward compatibility and hurting existing users in order to remove the strange "To an explicit pushURL, insteadOf rewriting will not apply" exception.

The reason I didn't bring up the possible breakage of "documented behaviour" in the earlier review of this series is exactly because that special case was unintuitive, so you do not have to argue it is strange, unintuitive, and would not be a way we would have designed the system if we knew better. I already agree to that point, and I think others do, too. There is a gap between "We would design it differently if we were building it now with what we know" and "We should change it and make it ideal" and the gap is called existing users.

These two are unrelated and independent.

I suspect that Ram's "triangular" series, when it matures, will help your "pull from there, push to another" workflow in a different way. You will just define two remotes for these two places, and you may no longer need "pushInsteadOf is not ignored when you have pushURL" to solve your immediate issue.

But removing the "pushInsteadOf is ignored when explicit pushURL exists" may still be a worthwhile thing to do, even if you do not need it.