Re: GIT_DIR output from git worktree list

[Eric Sunshine <sunshine@sunshineco.com>]

On Wed, Sep 30, 2020 at 1:33 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Tue, Sep 29, 2020 at 1:31 PM Gabriel Nützi <gnuetzi@gmail.com> wrote:
> > When you do move the .git folder somewhere else:
> > git init Test && cd Test && mv .git .git-b
> > git --git-dir=.git-b --work-tree . worktree list
> > the output is :
> > ..../Test/.git-b  0000000 [master]
> > Why is the output a .git Dir and not a worktree. I expected `.../Test`.
>
> I suppose one way to fix this would be to specially check if
> --work-tree or GIT_WORK_TREE is specified and use that value as the
> path of the main worktree. (This special case would only be used when
> computing the main worktree path; it would not be used when computing
> linked worktree paths.)

Fixing this is more complex than it seems at first glance. In fact,
I'm not sure there is a good fix at present without somehow recording
the location of the main worktree somewhere.

The problem is that determining the location of the main worktree by
consulting --work-tree or GIT_WORK_TREE when listing worktrees would
only give the desired result when `git worktree list` is run from
within the main worktree. If it is run within a secondary worktree,
then neither --work-tree nor GIT_WORK_TREE would be referencing the
main worktree (at best, they'd be referencing the secondary worktree),
which means that they would not help in determining the location of
the main worktree, thus `git worktree list` in a secondary worktree
would give different output.

Consulting core.worktree _may_ be doable, but it's iffy and would be
extra complicated because that configuration value is treated
specially. In particular, the value of core.worktree of the main
worktree is intentionally hidden from secondary worktrees. So, while
it _may_ be possible to write special-purpose code to go and seek out
the value of core.worktree for the main worktree by manually
spelunking various configuration files, it would be complicated. In
fact, it would be doubly complicated because it would require two
distinct implementations: one for when extensions.worktreeConfig is
enabled and one for when it is not.

The fact that the output of `git worktree list` would differ depending
upon whether it is run in the main worktree or a secondary worktree
(and whether core.worktree is configured or --work-tree or
GIT_WORK_TREE is used) makes me quite hesitant about these approaches.
I worry that such inconsistency would be perceived as instability, as
well as making it difficult to script `git worktree` reliably.

So, at present, I think any solution which can produce reliable,
consistent output may need to record the path of the main worktree
somewhere, but I haven't thought too deeply yet about how to do that
cleanly (while also taking other Git implementations into account).