fetch-all-upstreams: default branch name tracks upstream rather than owner's fork

[salewski]

This issue pertains the ads-github-fetch-all-upstreams(1) tool, as included with ads-github-tools-0.3.5 (released 2022-10-26), and (probably) all previous versions.

    $ ads-github-fetch-all-upstreams --version
    ads-github-fetch-all-upstreams 0.3.5  (built: 2022-10-26 03:00:34)
    Copyright (C) 2016, 2017, 2019, 2020 Alan D. Salewski
    License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    Written by Alan D. Salewski.

When cloning a GitHub fork like so:

    $ ads-github-fetch-all-upstreams -vcu -- some-repo-name

(which is a typical invocation) the branch of the newly created working directory reflects the default branch name of the upstream repo rather than the GitHub fork of that repo. This behavior is currently inherited from the underlying git-hub tool used by ads-github-fetch-all-upstreams when cloning a repository: the git-hub tool actually clones the upstream repo, and then adds a Git "remote" for the GitHub fork (of that upstream repo) that it names origin.

Ordinarily, this behavior is fine, and does not cause any problems, because default branch names tend to not change much in practice for most projects. The name of the default branch of a user's GitHub fork is inherited from the upstream repo at the time the fork is created. Unless a user takes explicit action to change the default branch of the fork, the default branch of the fork simply reflects the default (and typically unchanged) branch of the upstream project, and over time they happen to continue to match.

However, there is a scenario in which it can lead to surprises in that the branch of the working directory may not be what the user expects. The expectation of the user is that the working directory will reflect the default branch name of that user's GitHub fork (for those repos that happen to be forks rather than original sources). If the upstream project changes its default branch between the time in which the fork was created and the time in which that fork is cloned via ads-github-fetch-all-upstreams, the user will be surprised to find that the branch used in the working directory is a checkout of the new default branch as configured in the upstream project, rather than the default branch of the user's own GitHub fork of that project.

The ads-github-fetch-all-upstreams tool should be modified to ensure that upon an initial clone of a repository, the branch used for the Git working directory reflects the default branch of that user's GitHub fork (rather than the default branch of the upstream repo).

Ideally, this would be achieved without first transitioning through the current behavior. That is, we would not want to simply add an additional 'git checkout' step if the above situation is detected, because that would then have the unwanted effect of creating the local branch tracking the upstream default branch. Sure it could be deleted, but it would be better to just make the tool behave in the expected way without needing to do that sort of post-cloning cleanup.