Add option to reset index when updating branch that is checked out in a different worktree

[marcomasser]

This seems to be a quirk of Git and this apparently cannot be solved with a Git configuration change, so it would be nice if Fork could do it automatically.

For example:

• Worktree A has branch main checked out, worktree B has another branch checked out
• Fetch remote changes with main having remote changes
• Switch to worktree B, then fast-forward main
• Switch to worktree A (which has main checked out) and note that its index has all the necessary changes staged to revert the fast-forward

This is apparently because Git updates the main branch reference to point to the new commit and also updates the working directory files in worktree A to match the new main state. But it doesn’t automatically update worktree A’s index to match. A simple git reset or git reset --mixed HEAD fixes that, but it would be nice if Fork had an option to do that automatically.

[DanPristupov]

• Worktree A has branch main checked out, worktree B has another branch checked out
  ...
• Switch to worktree B, then fast-forward main

We should disable fast-forward for worktree branches.

A simple git reset or git reset --mixed HEAD fixes that, but it would be nice if Fork had an option to do that automatically.

No, this would erase the uncommitted changes.

[marcomasser]

• Worktree A has branch main checked out, worktree B has another branch checked out
  ...
• Switch to worktree B, then fast-forward main

We should disable fast-forward for worktree branches.

OK, then how about instead of disabling it, replace the action with one that switches to the worktree and perform the fast-forward there? That would fix the issue with the unwanted staged changes and it would avoid a user being disappointed by not being able to do the fast-forward. Any issues that could come up by uncommitted local changes would be handled as they are handled when no worktrees are involved because the UI simply switches the worktree beforehand.