Re: git worktree, submodule and force checkout/switch

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

 



Federico Kircheis <federico.kircheis@xxxxxxxxx> writes:

> Hello to everyone,
>
> I would like to report what I believe is a bug, or at least an 
> inconsistent behavior when using submodules and worktrees.
>
>
> Consider following test-case
>
> ----
> # create 2 repositories with one commit
> mkdir repo1 && (cd repo1 && git init && git commit --allow-empty -m "repo1")
> mkdir repo2 && (cd repo2 && git init && git commit --allow-empty -m "repo2")
>
> # add submodule, a couple of branches, and a worktree
> cd repo1
> git submodule add ../repo2 && git commit -m "add submodule"
> git switch -c branch1
> git switch -c branch2
> git worktree add ../repo1.w --detach
>
>
> # test switch in the worktree
> cd ../repo1.w
> # git switch works
> git switch --recurse-submodule branch1
> git switch --recurse-submodule master
> #git submodule update # (1)
> cat .git
> cat .gitmodules
> cat repo2/.git # (2)
> git switch --force branch1 # (3)error if no submodule update
> ----
>
>
> Notice that if one forgets to git submodule update (1) before git switch 
> --force branch1, even when using --recurse-submodule, there is no 
> submodule, as repo1.w/repo2/ is empty (2).
>
> It is confusing/unexpected that git switch --force fails and creates a 
> repo1.w/repo2/.git file pointing to the wrong location.
>
>
> As comparison, when cloning a repository and forgetting to do "git 
> submodule update", then "git switch --force branch1" works as expected:
>
>
>
> ----
> # create 2 repositories with one commit
> mkdir repo1 && (cd repo1 && git init && git commit --allow-empty -m "repo1")
> mkdir repo2 && (cd repo2 && git init && git commit --allow-empty -m "repo2")
>
> cd repo1
> git submodule add ../repo2 && git commit -m "add submodule"
> git switch -c branch1
> git switch -c branch2
>
> cd ..
> git clone repo1 repo1.c
> cd repo1.c
> git switch branch2
> git switch --force branch1 # works, event without git submodule update
> ----
>
>
>
>
> Notice:
> In both cases "git switch" and "git checkout" behave the same.
> Also the parameter "--recurse-submodule" does not change anything.
>
>
> Best
>
> Federico
>
>
> PS: I'm not subscribed to the mailing list (yet), so please keep me in CC.

Thanks for the report! This is very cosmetically similar to another bug
that Elijah (cc-ed) sent a patch for [1]. However, in my testing, the
test case doesn't even pass in v2.34.0, which doesn't have en/keep-cwd
(which is the branch that introduced the motivation for [1]).

So despite the unfortunate timing, I am inclined to think that this is a
longstanding issue with worktrees and submodules (and not a recent
regression in 2.35). I'm sending this out quickly just to say that it's
not a regression, and I might take a closer look when I have time.

This is the test case I used:

  test_expect_success 'bugreport' '
    # create 2 repositories with one commit
    mkdir repo1 && (cd repo1 && git init && git commit --allow-empty -m "repo1") &&
    mkdir repo2 && (cd repo2 && git init && git commit --allow-empty -m "repo2") &&

    # add submodule, a couple of branches, and a worktree
    cd repo1 &&
    git submodule add ../repo2 && git commit -m "add submodule" &&
    git switch -c branch1 &&
    git switch -c branch2 &&
    git worktree add ../repo1.w --detach &&

    # test switch in the worktree
    cd ../repo1.w &&
    # git switch works
    git switch --recurse-submodules branch1 &&
    git switch --recurse-submodules main &&
    cat .git &&
    cat .gitmodules &&
    cat repo2/.git &&
    git switch --force branch1
  '

[1] https://lore.kernel.org/git/pull.1205.git.git.1643161426138.gitgitgadget@xxxxxxxxx



[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