{"thread":{"id":"56552","subject":"Git submodule lists reference to a different tag than specified when checking out tag for submodule","startedAt":"2021-09-21T02:22:49Z","lastAt":"2021-09-21T05:16:57Z","messageCount":2,"participants":["Sergii Shmarkatiuk","Bryan Turner"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"436527","messageId":"CADzhcq7uoSji_PwTDU1zkgB-xWDSn5mQ+55+3JX_wkOr2s7H9w@mail.gmail.com","threadId":"56552","inReplyTo":null,"subject":"Git submodule lists reference to a different tag than specified when checking out tag for submodule","fromName":"Sergii Shmarkatiuk","fromEmail":"sergii.shmarkatiuk@gmail.com","sentAt":"2021-09-20T18:10:39Z","receivedAt":"2021-09-21T02:22:49Z","isPatch":false,"sender":{"key":"sergii.shmarkatiuk@gmail.com","avatar":null},"body":"Hi! I want to report an unexpected behavior of the latest version of\ngit that I faced today.\n\n> What did you do before the bug happened? (Steps to reproduce your issue)\n\nI have initialized two tags Dev/0.x.0 and User/0.x.0 in a repository\nthat is referenced as a submodule in another repository. Both tags\nrefer to the latest commit. First I created Dev/0.x.0, then\nUser/0.x.0:\n\ncd ~/projects/repo1\ngit tag Dev/0.x.0\ngit tag User/0.x.0\ngit push --tags\n\ncd ~/projects/repo2\ngit submodule add https://path-to-repo1/repo1.git\ncd repo1\ngit checkout User/0.x.0\ncd ..\ngit add repo1\ngit commit -m \"moved repo1 to the tag User/0.x.0\"\ngit push\n\n> What did you expect to happen? (Expected behavior)\n\nAfter performing all the steps above I expected the output of the 'git\nsubmodule' command to look as follows:\ngit submodule\n c575d777d33a0f1095875c7b55753eb59a51daba repo1 (User/0.x.0)\n\n> What happened instead? (Actual behavior)\n\nInstead, output looks as follows:\n\ngit submodule\n c575d777d33a0f1095875c7b55753eb59a51daba repo1 (Dev/0.x.0)\n\n> What's different between what you expected and what actually happened?\n\nSubmodule references different tag than specified in the checkout\ncommand (Dev/0.x.0 instead of User/0.x.0)\n\n[System Info]\ngit version:\ngit version 2.33.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.11.0-34-generic #36~20.04.1-Ubuntu SMP Fri Aug 27\n08:06:32 UTC 2021 x86_64\ncompiler info: gnuc: 9.3\nlibc info: glibc: 2.31\n$SHELL (typically, interactive shell): /bin/bash\n"},{"id":"436568","messageId":"CAGyf7-FAHJOb6iQYqYNt0WSk+zUHUJ_FjrU1xis1bBQd9Z6KPQ@mail.gmail.com","threadId":"56552","inReplyTo":"CADzhcq7uoSji_PwTDU1zkgB-xWDSn5mQ+55+3JX_wkOr2s7H9w@mail.gmail.com","subject":"Re: Git submodule lists reference to a different tag than specified when checking out tag for submodule","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2021-09-21T05:16:44Z","receivedAt":"2021-09-21T05:16:57Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Mon, Sep 20, 2021 at 7:22 PM Sergii Shmarkatiuk\n<sergii.shmarkatiuk@gmail.com> wrote:\n>\n> Hi! I want to report an unexpected behavior of the latest version of\n> git that I faced today.\n>\n> > What did you do before the bug happened? (Steps to reproduce your issue)\n>\n> I have initialized two tags Dev/0.x.0 and User/0.x.0 in a repository\n> that is referenced as a submodule in another repository. Both tags\n> refer to the latest commit. First I created Dev/0.x.0, then\n> User/0.x.0:\n>\n> cd ~/projects/repo1\n> git tag Dev/0.x.0\n> git tag User/0.x.0\n> git push --tags\n>\n> cd ~/projects/repo2\n> git submodule add https://path-to-repo1/repo1.git\n> cd repo1\n> git checkout User/0.x.0\n> cd ..\n> git add repo1\n> git commit -m \"moved repo1 to the tag User/0.x.0\"\n> git push\n>\n> > What did you expect to happen? (Expected behavior)\n>\n> After performing all the steps above I expected the output of the 'git\n> submodule' command to look as follows:\n> git submodule\n>  c575d777d33a0f1095875c7b55753eb59a51daba repo1 (User/0.x.0)\n>\n> > What happened instead? (Actual behavior)\n>\n> Instead, output looks as follows:\n>\n> git submodule\n>  c575d777d33a0f1095875c7b55753eb59a51daba repo1 (Dev/0.x.0)\n\nI suspect the answer here is going to be that this is how it's\ndesigned. The \"commit\" entry in the tree records exactly that--the\ncommit hash in the submodule repository; it doesn't record any name.\nThat means any ref name shown has to be inferred. Couple that with the\nfact that ref names are alphabetized (so the \"Dev\" version of the tag\nwill always appear first) and the \"Dev\" tag will be the one it shows.\n\nThis same issue existed for \"git clone\" for quite a while, before Git\nstarted including symref details for \"HEAD\" explicitly in the wire\nprotocol. Before that, the client would see \"HEAD <some-hash>\" and it\nwould find the first ref matching that hash and it would check out\nthat ref. The end result was a lot of bugs being raised (both here on\nthe list and in issue trackers for forges like Bitbucket Server)\nbecause Git was checking out the \"wrong branch\"--and sometimes\n\"randomly\" (for example if a workflow is in use where multiple refs\n_sometimes_ address the same commit hash, but don't always).\n\n>\n> > What's different between what you expected and what actually happened?\n>\n> Submodule references different tag than specified in the checkout\n> command (Dev/0.x.0 instead of User/0.x.0)\n>\n> [System Info]\n> git version:\n> git version 2.33.0\n> cpu: x86_64\n> no commit associated with this build\n> sizeof-long: 8\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> uname: Linux 5.11.0-34-generic #36~20.04.1-Ubuntu SMP Fri Aug 27\n> 08:06:32 UTC 2021 x86_64\n> compiler info: gnuc: 9.3\n> libc info: glibc: 2.31\n> $SHELL (typically, interactive shell): /bin/bash\n"}]}