Re: GIT_DIR output from git worktree list

["Ganriel Nützi" <gnuetzi@gmail.com>]

As of your rational, wouldn‘t it be good anyway to have a file „worktree“ inside the .git dir (of the worktree) containing the path to the main worktree? So to speak any worktree always has a .git dir with a back link to its main worktree (the existence of the git dir might pose other problems?) 



Von meinem iPhone gesendet

> Am 07.12.2020 um 05:34 schrieb 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).