This is related to:
The underlying git hub tool (see sociomantic-tsunami/git-hub) that is used when cloning repositories changed behavior in that project's version 1.0.0 to make the triangular workflow the default, and also to name the git remote associated with your GitHub fork fork rather than origin. Because our ads-github-fetch-all-upstreams tool is not explicitly requesting the non-triangular setup (it used to be the default), repos cloned recently are setup with the triangular workflow.
The ads-github-fetch-all-upstreams tool should be updated to require git-hub 1.0.0 or newer, and should explicitly control it's behavior to not use a triangular setup (the author's preference). A new command line option should be required to allow the user to request that a triangular setup be used.
See also issue #46 on the higher-level rationale for prefering a non-triangular workflow as the default. In short, a user cloning a GitHub fork directly on the command line using git(1) would, by default, have a local repo configured to pull and push to the single "origin" remote. We want to keep the default behavior of the ads-github-tools consistent with that default behavior (but allow the user to override the default behavior, as outlined above).
UPDATE (2020-10-12): Since this issue was originally written, the author has changed his opinion on whether the triangular workflow should be the default. The ads-github-fetch-all-upstreams program should continue to use a triangular workflow by default, but should provide a --no-triangular option to allow the user to choose the old behavior. For symmetry, a --triangular option can be provided to make clear the desired behavior, even though that will be the default.
So why the change? Two reasons:
- In practice, when using a repo cloned for a non-triangular workflow, the author always changes the default branch to track the branch of the same name from the "upstream" repo rather than the "origin" repo. Specifying that the newly clone repo should be configured to support a triangular workflow would make this step unnecessary; it would already be configured that way.
- The author does not rely very much on the default pull and push targets; always specifying the remotes explicitly (
git remote update foo and git push foo whatever) make the defaults that would otherwise be used irrelevant, practically speaking.
Note that (1) negates the rationale for sticking more closely to the default configuration obtained by doing a direct git clone of a repo. Such a config has only one remote ("origin"). Once an "upstream" remote is added, it is generally more useful to ask "how far away is my default branch than that of upstream?" than asking the same relative to the origin remote.
This is related to:
The underlying
git hubtool (see sociomantic-tsunami/git-hub) that is used when cloning repositories changed behavior in that project's version 1.0.0 to make the triangular workflow the default, and also to name the git remote associated with your GitHub forkforkrather thanorigin. Because ourads-github-fetch-all-upstreamstool is not explicitly requesting the non-triangular setup (it used to be the default), repos cloned recently are setup with the triangular workflow.Theads-github-fetch-all-upstreamstool should be updated to requiregit-hub1.0.0 or newer, and should explicitly control it's behavior to not use a triangular setup (the author's preference). A new command line option should be required to allow the user to request that a triangular setup be used.See also issue #46 on the higher-level rationale for prefering a non-triangular workflow as the default. In short, a user cloning a GitHub fork directly on the command line usinggit(1)would, by default, have a local repo configured to pull and push to the single "origin" remote. We want to keep the default behavior of theads-github-toolsconsistent with that default behavior (but allow the user to override the default behavior, as outlined above).UPDATE (2020-10-12): Since this issue was originally written, the author has changed his opinion on whether the triangular workflow should be the default. The
ads-github-fetch-all-upstreamsprogram should continue to use a triangular workflow by default, but should provide a--no-triangularoption to allow the user to choose the old behavior. For symmetry, a--triangularoption can be provided to make clear the desired behavior, even though that will be the default.So why the change? Two reasons:
git remote update fooandgit push foo whatever) make the defaults that would otherwise be used irrelevant, practically speaking.Note that (1) negates the rationale for sticking more closely to the default configuration obtained by doing a direct
git cloneof a repo. Such a config has only one remote ("origin"). Once an "upstream" remote is added, it is generally more useful to ask "how far away is my default branch than that of upstream?" than asking the same relative to the origin remote.