Hi! I want to report an unexpected behavior of the latest version of
git that I faced today.
What did you do before the bug happened? (Steps to reproduce your issue)
I have initialized two tags Dev/0.x.0 and User/0.x.0 in a repository
that is referenced as a submodule in another repository. Both tags
refer to the latest commit. First I created Dev/0.x.0, then
User/0.x.0:
cd ~/projects/repo1
git tag Dev/0.x.0
git tag User/0.x.0
git push --tags
cd ~/projects/repo2
git submodule add https://path-to-repo1/repo1.git
cd repo1
git checkout User/0.x.0
cd ..
git add repo1
git commit -m "moved repo1 to the tag User/0.x.0"
git push
What did you expect to happen? (Expected behavior)
After performing all the steps above I expected the output of the 'git
submodule' command to look as follows:
git submodule
c575d777d33a0f1095875c7b55753eb59a51daba repo1 (User/0.x.0)
What happened instead? (Actual behavior)
Instead, output looks as follows:
git submodule
c575d777d33a0f1095875c7b55753eb59a51daba repo1 (Dev/0.x.0)
What's different between what you expected and what actually happened?
Submodule references different tag than specified in the checkout
command (Dev/0.x.0 instead of User/0.x.0)
[System Info]
git version:
git version 2.33.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.11.0-34-generic #36~20.04.1-Ubuntu SMP Fri Aug 27
08:06:32 UTC 2021 x86_64
compiler info: gnuc: 9.3
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/bash
On Mon, Sep 20, 2021 at 7:22 PM Sergii Shmarkatiuk
[off-list ref] wrote:
Hi! I want to report an unexpected behavior of the latest version of
git that I faced today.
quoted
What did you do before the bug happened? (Steps to reproduce your issue)
I have initialized two tags Dev/0.x.0 and User/0.x.0 in a repository
that is referenced as a submodule in another repository. Both tags
refer to the latest commit. First I created Dev/0.x.0, then
User/0.x.0:
cd ~/projects/repo1
git tag Dev/0.x.0
git tag User/0.x.0
git push --tags
cd ~/projects/repo2
git submodule add https://path-to-repo1/repo1.git
cd repo1
git checkout User/0.x.0
cd ..
git add repo1
git commit -m "moved repo1 to the tag User/0.x.0"
git push
quoted
What did you expect to happen? (Expected behavior)
After performing all the steps above I expected the output of the 'git
submodule' command to look as follows:
git submodule
c575d777d33a0f1095875c7b55753eb59a51daba repo1 (User/0.x.0)
quoted
What happened instead? (Actual behavior)
Instead, output looks as follows:
git submodule
c575d777d33a0f1095875c7b55753eb59a51daba repo1 (Dev/0.x.0)
I suspect the answer here is going to be that this is how it's
designed. The "commit" entry in the tree records exactly that--the
commit hash in the submodule repository; it doesn't record any name.
That means any ref name shown has to be inferred. Couple that with the
fact that ref names are alphabetized (so the "Dev" version of the tag
will always appear first) and the "Dev" tag will be the one it shows.
This same issue existed for "git clone" for quite a while, before Git
started including symref details for "HEAD" explicitly in the wire
protocol. Before that, the client would see "HEAD <some-hash>" and it
would find the first ref matching that hash and it would check out
that ref. The end result was a lot of bugs being raised (both here on
the list and in issue trackers for forges like Bitbucket Server)
because Git was checking out the "wrong branch"--and sometimes
"randomly" (for example if a workflow is in use where multiple refs
_sometimes_ address the same commit hash, but don't always).
quoted
What's different between what you expected and what actually happened?
Submodule references different tag than specified in the checkout
command (Dev/0.x.0 instead of User/0.x.0)
[System Info]
git version:
git version 2.33.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.11.0-34-generic #36~20.04.1-Ubuntu SMP Fri Aug 27
08:06:32 UTC 2021 x86_64
compiler info: gnuc: 9.3
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/bash