Support for git worktree

[vzam]

Gittyup is great but it does not fit a workflow including git worktree very well. It would be great to see such a feature implemented.

[Murmele]

Hi,

can you explain more about it?

[vzam]

Sure, I can explain how it benefits myself. In my work, I am often interrupted by bugs, PR reviews and things that pop up with a higher priority and before I was using worktrees I had several copies of the repository to work on, such that I wouldn't have to create tons of WIP commits or stash the changes before changing to a different branch and topic. Worktree basically helps doing that, it is integrated into git and it allows creating these copies of the repository on the fly, to work on a topic that comes up and be closed after the work was finished. It makes context switching much easier and allows to quickly jump into some code to look at with the colleagues. Compared to the approach of creating copies of the repository by hand, it shares the .git data and therefore to update all worktrees, you have to do only one fetch, you have the same .git configuration for all worktrees and you can quickly create and destroy those copies as necessary. The feature is documented here.

[jensenr30]

@vzam I don't use git worktree myself, but I know some people really like it for the reasons you mentioned.

As a user of git worktree, can you provide sketches, diagrams, or descriptions of how Gittyup might be modified/extended to accommodate users of the worktree workflow?

[vzam]

I will work something out and follow up with it, I need to familiarize myself better with the feature in git itself.

[vzam]

@jensenr30 I think it makes most sense to first implement the basic functionality of switching worktrees and improve from there, so here are my thoughts:

1. Listing and Selecting Worktrees

git worktree list

List details of each worktree. The main worktree is listed first, followed by each of the linked worktrees. The output details include whether the worktree is bare, the revision currently checked out, the branch currently checked out (or "detached HEAD" if none), "locked" if the worktree is locked, "prunable" if the worktree can be pruned by the prune command.

• Open repository reports an error when a worktree is opened
  • git_repository_open does not support them and there seems to be no other function which is able to open the repository from a worktree
• Show the available worktrees
  • Always show the main worktree first
  • Show the currently checked out branch or the commit id for each worktree
  • May show flags bare, locked, prunable as they could help troubleshooting
    • Showing the bare flag is debatable, I think the app is not used in those contexts where bare repositories are used
  • Refresh the app state either with a button or automatically by watching the git worktrees or when the app is focused, because changes could be happening in the terminal
  • The worktree selection could be integrated into a new tab of the expanded dropdown where the branch can also be selected
  • If a repository has worktrees, instead of showing the branch name such as main, show worktree/main in collapsed state of the dropdown, where worktree is the name of the current worktree or just / (when the branch is on the main worktree of the repo). The name is the last directory of the path to the worktree, they are usually in the same directory. In case they are not, a tooltip could be shown on hover, containing the full path to the worktree.
  • Usually there should not be "too many" worktrees, but consider that the list could grow larger than the available space
• Select one of the worktrees git_repository_open_from_worktree
  • The app behaves the same as switching a branch
  • Staged and unstaged changes have to be refreshed if that wouldn't already happen
  • An error is reported when the worktree cannot be opened
    • Usually this will be the case when the worktree is prunable (not there) or locked (not always there, such as when on an external drive)
• Disallow switching to a branch which is already open in an other worktree
  • This is not allowed using worktrees and will result in an error

Is that something that you can work with? After this is done, the next iteration could allow adding and removing worktrees.