Lazygit crashes on worktree with bare repo

[mariuskimmina]

I have a repo that I cloned with

git clone --bare [email protected]:example/example.git example

And added the main branch as a worktree

git worktree add main

Now, if I go into the main directory and I tree to run lazygit it just crashes after opening for like half a second.
I cannot get the full panic because it also leaves my terminal in a messy state.

Lazygit version: commit=5e388e21c8ca6aa883dbcbe45c47f6fdd5116815, build date=2023-08-07T14:05:48Z, build source=binaryRelease, version=0.40.2, os=linux, arch=amd64, git version=2.34.1

(thanks for all the work that went into lazygit, been loving it for a while now)

[mark2185]

Can't reproduce on v0.40.2, so just to confirm the steps needed:

$> git clone [email protected]:jesseduffield/lazygit test
$> cd test
$> git worktree add main
$> cd main
$> lazygit

Is this correct?

[mariuskimmina]

@mark2185 Interesting, it really doesn't reproduce on the lazygit repo. The repo where I run into this panic is private so I can't just share that. I'll try to find what causes this and create an example that reproduces.

[mariuskimmina]

I did manage to catch the error now:

runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0xc020b80390 stack=[0xc020b80000, 0xc040b80000]
fatal error: stack overflow

runtime stack:
runtime.throw({0xcb82eb?, 0x12fa7c0?})
        /opt/hostedtoolcache/go/1.20.7/x64/src/runtime/panic.go:1047 +0x5d fp=0xc000791e18 sp=0xc000791de8 pc=0x43535d
runtime.newstack()
        /opt/hostedtoolcache/go/1.20.7/x64/src/runtime/stack.go:1105 +0x5bd fp=0xc000791fc8 sp=0xc000791e18 pc=0x44f23d
runtime.morestack()
        /opt/hostedtoolcache/go/1.20.7/x64/src/runtime/asm_amd64.s:574 +0x8b fp=0xc000791fd0 sp=0xc000791fc8 pc=0x465f2b

goroutine 81 [running]:
strings.genSplit({0xc000a4a0a3, 0x31}, {0xddaa58, 0x1}, 0x0, 0xffffffffffffffff?)
        /opt/hostedtoolcache/go/1.20.7/x64/src/strings/strings.go:233 +0x239 fp=0xc020b803a0 sp=0xc020b80398 pc=0x484479
strings.Split(...)

...

[mark2185]

Does the repo have symlinks? Does it crash if the worktree is in a dir outside of the bare clone?

[jwhitley]

This may be related to a bare-repo crash in #3175, which is fixed in (currently open) PR #3183. If you're feeling ambitious, pull my branch in that PR and give it a whirl. Otherwise, retest after that PR lands and is released in hopefully not too long.

[mariuskimmina]

I tried it with your PR branch but I still get this crash.

Also, the repo does not have symlinks but it does have additional repos cloned inside it.
If I try to use worktrees on the same repo but with a normal clone instead of a bare clone it seems to work fine.

[jwhitley]

Thanks for the feedback on the PR. I just tried it with the PR branch, and I'm unable to repro. I used a workflow similar to the one above, but I don't place the worktree inside of the bare repo, but next to it (by using env GIT_DIR=`realpath test` git worktree add main).

Obviously there's a crash here, but at least the basic regular/bare repo plus worktree cases seem to work. I think there's something about the specific private repo that's probably triggering the crash. You mentioned that there are other repos cloned into the first one? Are these submodules, or some more unusual clone-inside-a-clone workflow?

If you're able to discover a repro workflow, perhaps using dummy repositories that mimic the cloning organization you mention, that would be a huge help.

[jwhitley]

FYI, PR #3183 matured a bit, catching additional edge cases, and has been merged. If you have time, I'd love to know if your issue still reproduces on master. It's plausible that your scenario did eventually get fixed.

[mariuskimmina]

I switched jobs and am no longer able to access the repo that caused this issue, so I can't ever say if this is fixed or not.
To answer your last question, it was a more unusual clone-inside-clone workflow but even if I removed the clones inside the crash still occured.

From my point of view I would be fine with closing this issue as I won't be able to tell if the issue is fixed or not.

Again thank you for the great work you are doing here, I love using lazygit.

[voylin]

I'm having this issue right now. Just did a git clone --bare ... and git worktree add master. Without doing bare I was not having this issue at all in the repo.

[jwhitley]

@voylin I’ll see if I can repro tomorrow, my time. What version of lazygit are you using?

[jwhitley]

@voylin I'm still unable to repro, using lazygit v0.43.1. In samples above, this seemed to be repository dependent somehow. Is this happening for a public repository that you can share here? Alternatively, if you were able to create a public repo that reproduced the problem that would be a big help. Perhaps there's some unusual characteristic of your problem repo that's triggering the crash?

As it is, the underlying code had a major refactor and doesn't crash for similar workflows myself and others have tried in order to reproduce.

[voylin]

@voylin I’ll see if I can repro tomorrow, my time. What version of lazygit are you using?

Using Lazygit 0.43. I was using a public repo. I had this happen for https://github.com/VoylinsGamedevJourney/GoZen_lite. I don't know what went wrong, I don't rule out user error on my side though.

The steps I took were just a git clone bare of the repo, and adding the master branch with git worktree add. I got the problem fixed by just creating a folder with the repo name, using git clone but naming that folder master and in the same folder I added a worktree for the other branch. This works for me.

If you want I could try to replicate the issue and try to get some error logs or something to see if this is an actual issue or just me being dumb in setting up a git bare repo ^^"

[jwhitley]

Thanks @voylin, that's helpful. Let me see if I've got this right:

1. git clone --bare https://github.com/VoylinsGamedevJourney/GoZen_lite bare
2. env GIT_DIR=$(realpath bare) git worktree add main – this adds the worktree main alongside the repo bare, i.e. both have the same parent directory.
3. cd main
4. lazygit

That workflow isn't crashing for me on lazygit 0.43.1. If you're doing something different when you see the crash, it would be great to know what the exact steps are, since clearly some users hit roadblock here. (and even if the fix is "don't crash, and provide some usage guidance")

Last but not least, I also tried putting a worktree inside of the bare repo directory (which is super weird, since it's the git data directory), but that didn't crash either.

[christopher-harwell]

I am getting this error as well, specifically with worktrees. I can provide repro steps and try recloning the directory to verify if there is something specific to the git directory that is different.

[jwhitley]

@christopher-harwell That would be great if you can figure out repro steps. So far, no contributors have been able to repro this one.

[christopher-harwell]

I'm not able to repro in more than one directory, containing worktrees for a specific repo, but the only difference I've found between difference worktrees is that the directory containing the worktrees that this is crashing in has multiple worktrees in it. The ones that aren't only have 1.

I don't think this should affect anything, though.

I can keep looking today.

[christopher-harwell]

So I am having a hard time reproducing, but the one thing I have noticed as a difference between different repos is that one repo was created as a regular (non-bare) repository, I later created a worktree repo from this repo with a different name.

Note: I created these worktrees originally using this script:

#!/bin/bash

# Define the base directory for the worktrees
WORKTREE_BASE_DIR="repo.worktrees"

# Create the base directory if it doesn't exist
mkdir -p "$WORKTREE_BASE_DIR"

# Get the list of all branches
branches=$(git branch -r | grep -v '\->' | sed 's/origin\///' | sort | uniq)

# Loop through each branch and create a worktree
for branch in $branches; do
    # Define the path for the worktree
    worktree_path="$WORKTREE_BASE_DIR/$branch"

    # Check if the worktree already exists
    if [ -d "$worktree_path" ]; then
        echo "Worktree for branch '$branch' already exists at '$worktree_path'. Skipping..."
    else
        # Create the worktree
        echo "Creating worktree for branch '$branch' at '$worktree_path'..."
        git worktree add "$worktree_path" "origin/$branch"
    fi
done

echo "All worktrees have been created."%

I will update again if I find anything else

[GertBurger]

I stumbled upon the same error but likely via a different path, which means it might not be the exactly the same as above.
For some unknown reason I got a repo into the state where .git/worktrees/.../gitdir points to the checkout I am in. Effectively resulting in a loop.

i.e /some/path/my_repo/.git/worktrees/.../gitdir has the value /some/path/my_repo/.git

If this is a different issue then please ignore.