This issue is related to issue #39 and issue #40.
There is an ongoing tension in the way the ads-github-tools use the underlying git hub tool (see sociomantic-tsunami/git-hub), grounded in the fact that a clear decision has not yet been made as to what the default behavior of the tools ought to be. This is due in a small part to the changing default behavior of the git-hub program (as noted in the above referenced issues), but is mainly due to the ads-github-tools author's changing workflow preferences over time.
The two main issues are:
-
Triangular workflow vs. non-triangular workflow
-
The name of the git "remote" used for the user's GitHub forked repo
The primary reason the ads-github-tools use the git-hub(1) program is to leverage its existing capability to establish the "upstream" git remote. In particular, it is not the intention of ads-github-tools to impose any particular git-related tooling on the user; the default behavior of the programs in the ads-github-tools project should therefore endeavor to be minimally astonishing to users who are familiar with the default behavior of git-clone(1) and GitHub, but perhaps not with the git-hub(1) program.
OTOH, we also do not want to preclude leveraging a given user's knowledge of the widely used git-hub(1) program. Where it makes sense to do so, we want to defer to the user's preferences, and to "allow the user to delegate interface functions to a familiar program".
Toward that end, when deciding on the default behaviors for the ads-github-tools, we should lean in the direction of behaviors consistent with the default behaviors of both git(1) and GitHub functions. But where it makes sense, we should support first class mechanisms (configuration, command line options, etc.) to allow the user to adapt the tool to the user's workflow and tooling (rather than the other way around).
The triangular- vs. non-triangular workflow is documented in issue #39, and the particular approach suggested there is consistent with the general principle outlined above: a non-triangular workflow will be the default, but a mechanism will be provided to allow the user to request that a triangular workflow setup be used.
The current issue is concerned with (2) above. Because a git clone operation, by default, establishes an "origin" remote, that is the name the remote would have by default when a user directly clone's a repo from a GitHub fork. Therefore, the ads-github-tools will prefer the name "origin" over the name "fork" (which is the default name used for it by git-hub since version 1.0.0).
The git-hub program uses the git-config(1) key 'hub.forkremote' to control the name of the remote of the user's forked GitHub repo. The ads-github-tools programs should honor that setting, as well.
Similar for the config key 'hub.upstreamremote', which defaults to "upstream"; the ads-github-tools programs should honor that setting, as well. In the absense of the setting, however, "upstream" is also the preference of ads-github-tools for that remote, so the two sets of tools share a preference for the same default name for this one.
This issue is related to issue #39 and issue #40.
There is an ongoing tension in the way the
ads-github-toolsuse the underlyinggit hubtool (see sociomantic-tsunami/git-hub), grounded in the fact that a clear decision has not yet been made as to what the default behavior of the tools ought to be. This is due in a small part to the changing default behavior of thegit-hubprogram (as noted in the above referenced issues), but is mainly due to theads-github-toolsauthor's changing workflow preferences over time.The two main issues are:
Triangular workflow vs. non-triangular workflow
The name of the git "remote" used for the user's GitHub forked repo
The primary reason the
ads-github-toolsuse thegit-hub(1)program is to leverage its existing capability to establish the "upstream" git remote. In particular, it is not the intention ofads-github-toolsto impose any particular git-related tooling on the user; the default behavior of the programs in theads-github-toolsproject should therefore endeavor to be minimally astonishing to users who are familiar with the default behavior ofgit-clone(1)and GitHub, but perhaps not with thegit-hub(1)program.OTOH, we also do not want to preclude leveraging a given user's knowledge of the widely used
git-hub(1)program. Where it makes sense to do so, we want to defer to the user's preferences, and to "allow the user to delegate interface functions to a familiar program".Toward that end, when deciding on the default behaviors for the
ads-github-tools, we should lean in the direction of behaviors consistent with the default behaviors of bothgit(1)and GitHub functions. But where it makes sense, we should support first class mechanisms (configuration, command line options, etc.) to allow the user to adapt the tool to the user's workflow and tooling (rather than the other way around).The triangular- vs. non-triangular workflow is documented in issue #39, and the particular approach suggested there is consistent with the general principle outlined above: a non-triangular workflow will be the default, but a mechanism will be provided to allow the user to request that a triangular workflow setup be used.
The current issue is concerned with (2) above. Because a
git cloneoperation, by default, establishes an "origin" remote, that is the name the remote would have by default when a user directly clone's a repo from a GitHub fork. Therefore, theads-github-toolswill prefer the name "origin" over the name "fork" (which is the default name used for it bygit-hubsince version 1.0.0).The
git-hubprogram uses thegit-config(1)key 'hub.forkremote' to control the name of the remote of the user's forked GitHub repo. Theads-github-toolsprograms should honor that setting, as well.Similar for the config key '
hub.upstreamremote', which defaults to "upstream"; theads-github-toolsprograms should honor that setting, as well. In the absense of the setting, however, "upstream" is also the preference ofads-github-toolsfor that remote, so the two sets of tools share a preference for the same default name for this one.