Suggestion: Use git worktree to make diff code more simple and more robust

[matthijskooijman]

When using the diff output with old_type/new_type: git, the PCB git repository/worktree is used to switch to an older version to be used for diffing.

The current diff code takes care to properly restore the user's worktree and not throw away any changes, but this handling is quite complex already (it uses stashing, must handle submodules, takes into account detached head, etc.). In practice, I've seen one case where this handling failed (Something related to a submodule with uncomitted changes I think - I'm not entirely sure) and left me with a dirty worktree, and I can imagine it will also fail if the checkout would overwrite untracked files.

Thinking about this, I remembered git supports secondary worktrees, where a single repo has multiple independent worktrees. This sounds like it could be used to both simplify the kibot code, and make it more robust at the same time.

I have not investigated this idea in detail, but just wanted to put it here for consideration.

See docs at https://git-scm.com/docs/git-worktree

[set-soft]

Hi @matthijskooijman !

Didn't know about this mechanism. I implemented it and things seems to work well.

In practice, I've seen one case where this handling failed (Something related to a submodule with uncomitted changes I think - I'm not entirely sure)

I got a failure, but it was related to me doing wrong things with the submodules. But is true that using worktrees the worst side effect is to let an extra copy floating around.

Now the worktree mechanism is the default, but people can still use the stash mechasnism using a global variable (git_diff_strategy: stash)

[matthijskooijman]

Cool! I've looked over your code and it looks good to me. I've left one small improvement suggestion inline. Thanks!