Re: Git submodule lists reference to a different tag than specified when checking out tag for submodule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 20, 2021 at 7:22 PM Sergii Shmarkatiuk
<sergii.shmarkatiuk@xxxxxxxxx> wrote:
>
> 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)

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).

>
> > 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux