On Wed, Sep 30, 2020 at 1:33 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Tue, Sep 29, 2020 at 1:31 PM Gabriel Nützi <gnuetzi@xxxxxxxxx> 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).
