Worktree resolves to wrong path

[ibhagwan]

Current behavior 😯

When using a git bare repo with submodules (dotfiles) gix status results in a crash, it seels that the submodule is resolved to the wrong path (missing the username, should be /home/bhagwan...):

Text version of the error:

→ gix status
Error: Could not determine status for submodule at '.config/awesome/lain'

Caused by:
    Worktree root at '/home/.config/awesome/lain' is not a directory

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  10: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:360:3
  11: <unknown>

Expected behavior 🤔

Expected to return the output of the status command.

Git behavior

git status succeeds with no issue:

Output of submodule:

Output of worktree list:

Steps to reproduce 🕹

1. setup git repository with submodules in ~/dots
2. cd ~/dots
3. git config core.worktree $HOME
4. ln -fs ~/dots/.git ~/.git
5. cd ..
6. gix status (in $HOME)

If you wish to try it out, the process above is automated by my dotfiles install script.

[Byron]

Thanks a lot for reporting!

I think the issue seems to be that the worktree isn't correctly computed when core.worktree is used.

• git: /home/bhagwan/dots
• gix: /home/bhagwan

When trying it myself, with an empty repository, I am getting even more interesting results:

~ ( main) [?]
❯ gix worktree list
/Users/byron [main]

~ ( main) [?]
❯ git worktree list
/Users/byron/dev/testing  0000000 [main]

Git shows the original location of the repository, while gix shows the correct one. In any case, something is fishy.

[arumugamramaswamy]

Hi! I would like to try to tackle this issue:)

[Byron]

Yes please, thank you, go ahead. As long as you start with a test or two, the implementation that goes along with it should (nearly) write itself.

[arumugamramaswamy]

Hi, so I did a bit of digging and was able to reproduce the issue.

The main requirement for reproducing the issue seems to be symlinking the .git directory from the repo to another location. In the example provided above: ln -fs ~/dots/.git ~/.git

I can't seem to find any docs on whether this is something that git supports. @Byron, @ibhagwan can you point me to any resources about this?

[Byron]

That's great! Wouldn't you know if Git supports it by trying to run commands on that repository? From all I assumed, Git is fine with symlinks in that spot and handles them correctly.

If a test-case would be contributed, a fix wouldn't be far out from there.