Not starting when trying to use in submodule of symlinked submodule

[echasnovski]

Describe the bug When intending to use inside submodule of a symlinked submodule, there is this error with latest release (version 0.34):

2022/04/07 18:59:04 An error occurred! Please create an issue at: https://github.com/jesseduffield/lazygit/issues

*errors.errorString repository does not exist
/home/runner/work/lazygit/lazygit/main.go:145 (0xa8c8c5)
/opt/hostedtoolcache/go/1.16.15/x64/src/runtime/proc.go:225 (0x4389b6)
/opt/hostedtoolcache/go/1.16.15/x64/src/runtime/asm_amd64.s:1371 (0x46c5e1)

Everything works in the following scenarios:

• Use inside nested submodule but in original path of parent submodule.
• Use inside symlinked "parent" submodule.
• Use inside independent git repo inside symlinked "parent" submodule.

This seems like it should have been fixed in #789, but, unfortunately, I don't see this working.

To Reproduce Steps to reproduce the behavior:

1. Set up repo.
2. Set up submodule inside repo.
3. Make symlink to submodule.
4. Set up submodule inside submodule.
5. Go to directory of nested submodule inside symlink and try running lazygit (I see error).

For more context, this happens inside my dotfiles. It has submodule neovim/.config/nvim (link to repo), which I symlink to ~/.config/nvim while dotfiles are in ~/dotfiles. The nvim submodule in turn has many own submodules for plugins (in pack/plugins/opt directory). So trying to run lazygit:

• Fails when inside any of those plugin subdirectories in symlinked directory (like ~/.config/nvim/pack/plugins/opt/gitsigns).
• Works inside those subdirectories but not in symlinked path (like ~/dotfiles/neovim/.config/nvim/pack/plugins/opt/gitsigns).
• Works inside non-submodule of symlinked directory (like created git repo inside ~/.config/nvim/pack/plugins/opt).

Expected behavior lazygit can start in submodule of symlinked submodule.

Screenshots No screenshot.

Desktop (please complete the following information):

• OS: Xubuntu 20.04
• Lazygit Version: 0.34
• The last commit id if you built project from sources: commit=7be25a105d389a262ef040133a4270f2f745d255 (via lazygit --version).

Additional context Add any other context about the problem here.

[echasnovski]

For anyone with same problem: I seem to have managed to overcome this with lazygit --git-dir=$(git rev-parse --git-dir). Made an alias and works fine at the moment.

[arminveres]

This started appearing again in 0.40 for me. --git-dir doesn't event work... Works fine with 0.39.4

[echasnovski]

This started appearing again in 0.40 for me. --git-dir doesn't event work... Works fine with 0.39.4

Yeah, for me too. Had to spend about an hour to find the issue. Seems like something changed with how worktrees are handled.

I updated the alias to be lazygit --git-dir=$(git rev-parse --git-dir) --work-tree=$(realpath .). Works fine like this for me.

[arminveres]

Thanks @echasnovski, that solved it!

[jwhitley]

Hmm.. lazygit starts under PR #3183, but the symlinking in this issue appears to be a confusing case re: the normal submodule cases documented there. When cd'ed into the linked submodule, the correct behavior should be to show the submodule repo's info. Instead, lazygit thinks it's in the parent repo.

Correction: see next comment.

[jwhitley]

Correction: #3183 appears to work correctly for this case. I added a test case "doubleLinkedSubmoduleCase" to repotest.zsh that builds a repository with a two-level nested submodule, and a symlink into the inner submodule, ala:

repo/outerSubmodule/innerSubmodule

Lazygit works when cd'ing into a symlink in repo:

1. pointing to outerSubmodule
2. pointing to outerSubmodule/innerSubmodule

I believe no. 2 matches the repro for this issue. If not, I'd love a correction so I can craft a repro scenario.

Lazygit still has issues when cd'ing into a subdirectory of innerSubmodule via a symlink, but I believe that's effectively part of lazygit's known issues with running from repo subdirs.