feat: more support for worktrees

[colemickens]

Hi,

If I'm not mistaken, grm feels like a mix of declarative and imperative right now. While my repos are managed via the config file, it doesn't seem like worktrees are? That's from peeking at the config rust code, and just from my initial tests.

Stated another way - In the pursuit of having GRM be part of an ephemeral dev setup, I want to be able to feed GRM a config file that notes worktrees and their tracked remote branches, to re-instantiate my code tree.

I imagine something like:

trees:
- root: ~/code2
  repos
  - name: home-manager
    worktrees:
    - branch: main
      path: main/ # relative to the repo location
      tracks: origin/main
    - brach: cmhm
      path: cmhm/
      tracks: origin/cmhm
    remotes:
    - name: origin
      url: https://github.com/colemickens/home-manager
      type: https

I'm also thinking about the general UX of this, I almost want to be able to block the checkout/switching of branches except through GRM (even better, make the user edit the config file and re-run GRM to "realize" their code tree). I doubt that's possible though.

Maybe this is not a novel idea, but rather just not implemented yet?

[hakoerber]

Hey!

While my repos are managed via the config file, it doesn't seem like worktrees are?

You are correct, you cannot configure worktrees via config.

For me, worktrees are mostly an ephemeral thing, I create them for feature branches and remove them when I'm done. I only have persistent worktrees for long-living branches (like master and develop).

But I like the idea! I could think of two approaches for this feature:

• Exactly what you suggested, i.e. having the exact set of worktrees in configuration. You cannot really prevent people using git directly to modify worktrees, but it would make sense to deny most of the grm wt commands (at least add, delete & clean) when operating on such a repository.
• Having only a default set of worktrees configured. This would keep the long-lived worktrees in config management, while still allowing to use short-lived worktrees on a whim.

I'm open to both. Both approaches could be implemented, as they could coexist. The first would use your exact configuration suggestion, while the latter could use default_worktrees as the key instead.

Honestly, I won't be able to implement this feature, I also don't have a use case personally. But feel free to implement this, I'd be happy to merge the functionality!

[masaeedu]

This has been a blocker for me in adopting grm, because I already heavily use worktrees and have a lot of them littered about my ~/code. Using grm repos find local gives incorrect results in this case, since it thinks each worktree is an independent git repo.

[hakoerber]

@masaeedu maybe you can take a shot at the implementation? What do you think of the two approaches listed above?