Detection of existing worktrees

[teto]

hi,

I've just started using grm after looking into several git repo tool but this is the first one that seems to support the two features I was looking for : remote and worktree support. As usual I started without reading the doc with: grm repos find local ~/nova --format yaml > repositories.yml and grm was not able to detect my worktrees, or rather it added them as a proper clone, e.g., I ended up with 2 clones of the same project in repositories.yml while on my drive one is a clone and the other a worktree. I think this could be improved somehow ?

I read the doc about worktrees https://hakoerber.github.io/git-repo-manager/worktree_working.html and realized the soft was very opiniated and that I need a worktree per branch ~ I wonder if this

➜ grm wt convert
[✘] Ignored files found in repository, refusing to convert. Run git clean -f -d -X to remove them manually.

is really needed ? After converting the project and creating one worktree, I tried to relaunch the first command to see if it could register the worktrees but I got:

grm repos find local ~/nova --format yaml > repositories.yml
[!] Error opening repo /home/teto/nova/jinko2: NotFound 

~/nova/jinko2 
➜ git worktree list
fatal: not a git repository: /home/teto/nova/jinko/.git/worktrees/jinko2

so the conversion has to be run carefully as it destroyed my previous worktree ? Is there any technical reason for the worktrees to work as you suggest or is it just personal preference ?

[hakoerber]

Hey,

this is semi-related to #66. In short, worktree detection with repos find is not working properly right now.

[hakoerber]

I checked the code, and detect_worktree() should actually properly detect existing worktrees when using grm repos find local. But: this only goes for worktrees initially created by grm. If you used `git worktree add to create those worktrees, they will be detected as a separate repository.

It may be possible to merge multiple worktrees of the same repo into a single config item, but that would make the code very complex and has a few open questions:

• How to convert a bunch of existing worktrees into the structure that grm expects? That would involve some mving directories around and rewriting paths inside .git.
• What if the existing worktree config does not match what is expected by grm? Especially when thinking about branch prefixes and all that stuff.
• As grm find repos local only writes a config, we'd have to do conversion during application of that configuration. So the config is potentially invalid until application. Is this acceptable?

I personally do not see the use case (as I have no worktrees that are not managed by grm). If you want, we can work together on a design for detection & conversion of non-grm worktrees. For that, could you outline what your perfect workflow would look like?