Re: [RFC] Triangular Workflow: user friendly full implementation

["Philip Oakley" <philipoakley@iee.org>]

From: "Jordan DE GEA" <jordan.de-gea@grenoble-inp.org>
> 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)