Background
This code in the init script runs this to check out the master branch if present and readily available, and other just make a branch called that where we are now:
|
# The tests need a branch called master. |
|
git checkout master -- || git checkout -b master |
That is intended to cover, and does cover, the cases where master is available locally, or not available locally but available from one remote.
The master branch in GitPython is basically only for testing, and this has been so for some years. The default branch is main. The master branch is mostly just a ref for testing, and there is a lot of flexibility in where it points. The test suite needs a reflog at least a few entries long, so:
|
# The tests need a reflog history on the master branch. |
|
git reset --hard HEAD~1 |
|
git reset --hard HEAD~1 |
|
git reset --hard HEAD~1 |
Then master is reset to wherever we started anyway. The reason for all this, of course, is that the test suite uses the current repository (of GitPython itself, as well as its submodules) in test fixtures. I think we intend to change that at some point, but it has to be done carefully, so this intended high coupling between the test suite and the local GitPython repository remains for now.
When multiple remotes have it
When multiple remotes have a master branch and no local master branch exists, Git configuration determines what happens. But by default, an attempt to switch to a locally absent branch that is to be set up automatically from a remote will refuse to proceed if there is more than one, even if they point to the same commit.
As a result, we get:
ek@ELIAHKAGAN76BA CLANGARM64 /e/repos/GitPython (main)
$ ./init-tests-after-clone.sh
This operation will destroy locally modified files. Continue ? [N/y]: y
hint: If you meant to check out a remote tracking branch on, e.g. 'origin',
hint: you can do so by fully qualifying the name with the --track option:
hint:
hint: git checkout --track origin/<name>
hint:
hint: If you'd like to always have checkouts of an ambiguous <name> prefer
hint: one remote, e.g. the 'origin' remote, consider setting
hint: checkout.defaultRemote=origin in your config.
fatal: 'master' matched multiple (2) remote tracking branches
Switched to a new branch 'master'
HEAD is now at c7648c0c Merge pull request #2143 from gitpython-developers/contrbuting
HEAD is now at 5a294a6f bump version to 3.1.50
HEAD is now at d7b029f1 Merge pull request #2142 from gitpython-developers/fix-validate-config-key-newlines
HEAD is now at 7b83f7a9 Merge pull request #2144 from mvanhorn/osc/2016-clarify-execute-string-arg
Submodule 'gitdb' (https://github.com/gitpython-developers/gitdb.git) registered for path 'git/ext/gitdb'
Cloning into 'E:/repos/GitPython/git/ext/gitdb'...
Submodule path 'git/ext/gitdb': checked out '335c0f66173eecdc7b2597c2b6c3d1fde795df30'
Submodule 'smmap' (https://github.com/gitpython-developers/smmap.git) registered for path 'git/ext/gitdb/gitdb/ext/smmap'
Cloning into 'E:/repos/GitPython/git/ext/gitdb/gitdb/ext/smmap'...
Submodule path 'git/ext/gitdb/gitdb/ext/smmap': checked out 'c6b53d35deb82a38d5d07ca7712c1334a7a10c10'
Fetching origin
Fetching upstream
Fetching kip
This is mostly harmless, and arguably completely harmless. The only actual significant effect that would ordinarily occur is that the resets, done to ensure a deep enough reflog for reflog-related tests, are populated from more recent history.
However, it is unintuitive that adding (and fetching from) multiple remotes with master would affect which reflog entries the init script populates.
The fix
It should be enough to add a comment describing the behavior. There is probably no simple always-right thing to do besides that. It's probably excessively complex to treat the case where all upstream master branches reference the same commit specially. The bug, if it can be called that, is in the confusion about what reflog entries are populated.
If I don't identify any more serious effect of this, then I'll make that change, possibly as part of some larger PR.
Meta-discussion
I guess this a liminal case of an issue. I almost didn't report it. But I didn't want to forget it. In particular, whenever the test suite is changed to be less coupled with the checked-out GitPython repository itself, the precise semantics of the init script may be important, so I think it's best they be as clear as possible.
Background
This code in the init script runs this to check out the
masterbranch if present and readily available, and other just make a branch called that where we are now:GitPython/init-tests-after-clone.sh
Lines 42 to 43 in 7b83f7a
That is intended to cover, and does cover, the cases where
masteris available locally, or not available locally but available from one remote.The
masterbranch in GitPython is basically only for testing, and this has been so for some years. The default branch ismain. Themasterbranch is mostly just a ref for testing, and there is a lot of flexibility in where it points. The test suite needs a reflog at least a few entries long, so:GitPython/init-tests-after-clone.sh
Lines 45 to 48 in 7b83f7a
Then
masteris reset to wherever we started anyway. The reason for all this, of course, is that the test suite uses the current repository (of GitPython itself, as well as its submodules) in test fixtures. I think we intend to change that at some point, but it has to be done carefully, so this intended high coupling between the test suite and the local GitPython repository remains for now.When multiple remotes have it
When multiple remotes have a
masterbranch and no localmasterbranch exists, Git configuration determines what happens. But by default, an attempt to switch to a locally absent branch that is to be set up automatically from a remote will refuse to proceed if there is more than one, even if they point to the same commit.As a result, we get:
This is mostly harmless, and arguably completely harmless. The only actual significant effect that would ordinarily occur is that the resets, done to ensure a deep enough reflog for reflog-related tests, are populated from more recent history.
However, it is unintuitive that adding (and fetching from) multiple remotes with
masterwould affect which reflog entries the init script populates.The fix
It should be enough to add a comment describing the behavior. There is probably no simple always-right thing to do besides that. It's probably excessively complex to treat the case where all upstream
masterbranches reference the same commit specially. The bug, if it can be called that, is in the confusion about what reflog entries are populated.If I don't identify any more serious effect of this, then I'll make that change, possibly as part of some larger PR.
Meta-discussion
I guess this a liminal case of an issue. I almost didn't report it. But I didn't want to forget it. In particular, whenever the test suite is changed to be less coupled with the checked-out GitPython repository itself, the precise semantics of the init script may be important, so I think it's best they be as clear as possible.