From: "Jordan DE GEA" <jordan.de-gea@xxxxxxxxxxxxxxxx>
We are working on full implementation of triangular workflow feature.
For now, the main options available are:
- branch.<name>.pushRemote
- remote.pushDefault
And only setable by hands.
As it can be difficult to understand, here is what we want to do.
Context:
- One main remote repository, e.g. git/git.
- A remote fork (e.g. a GitHub fork) of git/git, e.g. me/git.
- A local clone of me/git on the machine
Purposes:
- the local branch master has to fetch to git/git by default
- the local branch master has to push to me/git by default
Configuration wanted:
- Add a remote to git/git e.g. `git remote add ...`
- Set the fetch remote for branch as default.
For now, we can do that by setting:
- branch.<name>.remote to git/git
- branch.<name>.pushRemote to me/git
But many options set `branch.<name>.remote`, a suitable solution is to
implement an option for the fetch for example.
Here is what we want to implement:
1.
a. add the config var: remote.fetchDefault
b. add the config var: branch.<name>.fetchRemote
c. add `git fetch --set-default` in order to set remote.fetchDefault
d. add `git fetch --set-remote` in order to set branch.<name>.fetchRemote
e. add `git pull --set-default` in order to set remote.fetchDefault
f. add `git pull --set-remote` in order to set branch.<name>.fetchRemote
2.
a. add `git push --set-default` in order to set remote.pushDefault
b. add `git push --set-remote` in order to set branch.<name>.pushRemote
What's your opinion about this feature ?
For me, the first step would be to actually document a (the?) Triangular
Workflow in the documentation, so we are all taking about the same broad
method.
At the moment there is a choice (assuming a ithub like service) of either
clone and then fork, or fork and clone the fork, which leave the user with
different fixups of their config's being required, so describing the easier
one would help folk.
Likewise there are missing terms such as for the third place (the personal
fork) that is neither the upstream, nor the local repo. Making sure the
terminology is crisp and clean will greatly ease any implementation issues.
And then there are the possible workflows...
--
Philip
(sorry for the rushed message, a long weekend beckons)
--
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