Rob Hoelz <rob@xxxxxxxx> 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.
--
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