Re: [RFC] Triangular Workflow: user friendly full implementation
- From
Philip Oakley <philipoakley@iee.org>
- Date
- May 27, 2016, 07:32 UTC
- Message-ID
- <D501BE7EF38A4CDF9ADB786B53CCFE0C@PhilipOakley>
- In-Reply-To
- <E83A9439-54C8-4925-8EE3-6AEEDD9416F3@grenoble-inp.org>
From: "Jordan DE GEA" <jordan.de-gea@grenoble-inp.org>
Show 46 quoted lines
> 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)