Fast-forward not checkouted branch results in new changes added to Files tab when using Git Worktree

[mnddm]

Describe the bug
Suppose I have the develop branch and make a worktree for my feature/xyz branch. Then, I jump into the feature/xyz worktree and do some work. After some time I want to make a back merge from the develop branch into the feature/xyz, because I clearly see in lazygit UI that develop (3) has 3 new commits. Currently I'm on the feature/xyz branch and I move the cursor (i.e. the highlighted "line") to develop and press f (fast-forward). The changes "fast-forwarded" fine but for some reason all the files from those 3 commits also appeared in the "Files" tab as edited and unstaged files.

Expected behavior
When I'm using Git Worktree and do fast-forward on not currently checkouted branch, the fast-forwarded changes should not be added to "Files" tab.

Version info:
commit=5e388e21c8ca6aa883dbcbe45c47f6fdd5116815, build date=2023-08-07T14:05:48Z, build source=binaryRelease, version=0.40.2, os=darwin, arch=amd64, git version=2.42.0

[nasava]

I also experience this problem. The files being updated on another worktree's branch show up in the current worktree.

[nasava]

I looked into the command what lazygit executes:

I originally cloned main_worktree, switched to a branch, and after that I created other_worktree with branch master.
Now when I do the (f)ast-forward command on master(worktree) with lazygit having main_worktree opened the following is executed:

git --git-dir /path/to/main_worktree/.git/worktrees/other_worktree pull --no-edit --ff-only origin master

I think this command has the main_worktree as working tree and changes that, as if the git folder .git/worktrees/other_worktree belonged to it instead of belonging to .git.

Maybe an additional --work-tree parameter should be specified or a -C shuld be used?

[john-mutuma]

This happen when I hit F to fast-forward a branch that is the HEAD of a different worktree, without first checking out to that worktree e.g. with the following workflow:

• Create a worktree with lazygit
• set a remote tracking branch for the new worktree's branch
• when there are updates to the set remote tracking branch and I want to fast-forward, I can do either of the following:
  - checkout the new worktree and fast-forward: this works fine.
  - fast-forward the new worktree branch by hitting F on the Local branches pane without switching to the new worktree.
  The latter fast-forwards the target branch ok, but new unwanted changes are added to my active worktree

To avoid this, as a matter of best practice, I have to switch into the relevant worktree before I fast-forward a branch that is it's current HEAD. i.e. I'd avoid fast-forwarding branches that are suffixed with (worktree) before I switch to their worktree. It can be a pain when you accidentally hit F on such a branch in the Local branches pane.

[john-mutuma]

As @nasava notes, adding --working-tree option besides the --git-dir works. I tested this by running the same lazygit generated pull command in my terminal (inside the parent worktree) but adding this option. It FFs the target worktree Ok without messing up with my current worktree.

Also, a standalone -C works as expected.

This, I also believe, is a painful bug when I imagine (and being a victim of) FF`ing a worktree branch with some uncommited/unstaged changes in my current work tree, and then all of a sudden, I get hundreds of File changes added to my current worktree.

@jesseduffield, @stefanhaller, I believe your plate is super-full right now, but you might know if there is some work around closing this issue and hopefully fixing the bug.

If not, it's something that I could be willing to take up soon when possible as a good-first-issue to contribute, with some guidance, to this amazing project.

I've perused the repo and noted that perhaps this code section could be the right place to begin? The solution I suppose would involve adding the worktree Path conditionally after this line?

Other potetial changes I can foresee rn:

• adding the Worktree path to the PullOptions

[jesseduffield]

@john-mutuma That seems reasonable to me. I've added a good first issue label: feel free to raise a PR and I can take a look at it.

We have an existing integration test here which it would be good to copy+paste and tweak it to match the bug that this issue is trying to solve. That will be a good way to confirm your code works.

Let me know if you have any questions

[jesseduffield]

Whoops: didn't realise you already raised a PR! I'll leave a comment on that

[stefanhaller]

Looks like this was fixed by #4051; closing.

[stefanhaller]

This problem popped up again with the newly added "auto-forward main branches" feature (added in v0.50). I didn't notice before because I only just recently started using worktrees myself. The fix is a different one in this case, we simply exclude those branches that are checked out by other worktrees from auto-forwarding (like we already exclude the currently checked out branch).

Fixed by #4833.