Adding support for git worktrees

[nlsantos]

Hi, @jorio. I've forked your repo to add support for git worktrees here. The existing tests pass, but I'd like your feedback if you think this warrants additional test cases specifically for worktrees.

I think it would involve basically duplicating the existing repo-oriented test cases, but targeting a worktree instead. That would obviously incur additional maintenance load, but maybe there's a better way?

FWIW, I'm looking to increase the chance of this fork getting upstreamed, as I rely on worktrees heavily.

Thank you.

[jorio]

Hi @nlsantos! I agree that first-class support for worktrees would be great to have. I don't think we need to duplicate all the repo-oriented test cases for now; we can start by testing a few use cases that currently fail with worktrees.

Can you describe the use case that you're solving in your fork?
I tried the scenario below and it worked no problem, so I'm guessing we're setting up worktrees differently:

• git clone --bare https://github.com/libgit2/pygit2
• cd pygit2.git
• git worktree add ../pygit2-worktree
• GitFourchette is able to open pygit2-worktree (as long as the worktree isn't a subdirectory of the bare repo)

[nlsantos]

That last note is exactly how I usually have worktrees setup, i.e.:

• git clone --bare https://github.com/libgit2/pygit2.git pygit2
• cd pygit2
• git worktree add main main

When I try to open the repo using the latest Flatpak version, I get the following:

Traceback (most recent call last):
repotask.py:1072, in _getNextToken
    token = next(flow)
            ^^^^^^^^^^
loadtasks.py:81, in flow
    repoModel = RepoModel(repo)
                ^^^^^^^^^^^^^^^
repomodel.py:192, in __init__
    self.superproject = repo.get_superproject()
                        ^^^^^^^^^^^^^^^^^^^^^^^
porcelain.py:1660, in get_superproject
    assert outer_repo.workdir.endswith("/")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'endswith'

I haven't had the chance to try my changes against the directory structure you've just outlined, but I will as soon as I get a bit more free time.

[jorio]

OK, I'm able to reproduce the error when the worktree is set up to be a subdirectory of a bare repo. I'll write a test for this use case, and I'll include your fix into version 1.6.0, which I'm planning to release Soon™. Thank you for reporting this!

[nlsantos]

My pleasure, and thank you for writing GitFourchette!

Should I open a PR?

[jorio]

A PR won't be necessary, I've cherrypicked your fix. New release coming soon. Thanks!

[nlsantos]

Okay, so just checked that my changes doesn't break GitFourchette when working with the directory structure you outlined, and it still loads. 😁