Allow provider to work with git worktrees

[thomasfinstad]

Currently it seems the provider does not support git worktrees very well.

I am trying to move to a worktree workflow for my machines to be able to more smoothly work on multiple branches at the same time, it would be nice to have the provider support as many work styles as possible to make the provider more universally useful.

I created some short scripts to illustrate the issue and show differences as it would be difficult for me to know what information is needed..

just run the scripts bash <script file> it will create directories and run terraform and remove the directories after.

This is a basic setup that is probably the most common, and it works fine:
basic-repo.txt

Seperating out the git dir also seems to work fine
seperate-git-dir.txt

Worktrees do not work how ever
worktree.txt

[sebhoss]

Yeah that's correct and I'm hurting by this myself as well. Unfortunately this restriction is due missing support for worktrees in go-git which is the library used in this provider for git integration. I briefly thought about switching to libgit2 or just shelling out to the users git command in order to improve this but haven't found the motivation to do such a big change yet..

[thomasfinstad]

I dont think using the git cli is a good option, I myself am looking into your provider explicitly to get away from any external dependencies outside of the terraform ecosystem.

I am not familiar with the inner workings of your provider at this point, or the library you use, so I can not say for sure, but it does look a little to me like there is some sort of worktree support: https://pkg.go.dev/github.com/go-git/go-git/v5#Worktree

[sebhoss]

Yeah I'm using that Worktree struct in this provider (e.g. https://github.com/metio/terraform-provider-git/blob/main/internal/provider/git_worktree.go) but that's not the git worktree support that we both want.

100% ack on the getting away from external dependencies part

[thomasfinstad]

Although it is not optimal, what about using the library you mentioned libgit2 for new features, and if you wish existing code can be ported over time? There shouldn't be any blockers to using two libraries with overlap in functionality, during a transition stage or even permanently.

[sebhoss]

Yeah that's https://libgit2.org/ which has a Go bindings at https://github.com/libgit2/git2go

Using two libs should not be an issue, however that git.Worktree struct from go-git is kinda central in this provider so replacing that would probably be most of the work to switch the entire provider to libgit2.

My current workaround for this is to clone each repo twice, once for 'manual' work (coding) that uses multiple worktrees and once again for automated work which does not use multiple worktrees and thus can be used with this provider. It annoys me every time I look at it so I'm definitely interested in finding a solution for this myself. I'm just not sure whether go-git is faster in supporting multiple worktrees or me finding the time/motivation to do something about it in this provider..

[thomasfinstad]

I understand the lack of time and motivation, but it does not seem like multiple worktrees is likely to happen anytime soon in go-git: go-git/go-git#41 (comment)

I would very much like to help, but I am not a great go coder, and have very limited time myself, it would probably take me a very long time to get to the point where I could start making changes to your code.

Would it be at all feasable to create the multiple worktree support with the new lib and basically start the new architecture without affecting / ripping out the old resources and data sources code?

[sebhoss]

Yeah I don't think worktree support in go-git is happening anytime soon either, but the same is true for switching to another lib in this provider - it won't happen soon (if at all) so if you need something now you have to look for something else.