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@xxxxxxxxxxxxxx>: > >> 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).
