GIT_DIR output from git worktree list

Hello,

When you do move the .git folder somewhere else:

git init Test && cd Test && mv .git .git-b

and then do

cd Test && 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`.

Thanks for the help. BR Gabriel

On Tue, Sep 29, 2020 at 1:31 PM Gabriel Nützi <gnuetzi@gmail.com> wrote:

Because the implementation doesn't really look for or know where the main worktree is. Instead, it's taking the path of the repository and stripping off "/.git" if present, and reporting that as the main worktree. Under normal circumstances this works just fine because either (a) the repository _is_ the .git directory within the main worktree, or (b) it's a bare repository and there is no main worktree, thus it reports the repository path instead of the non-existent main worktree.

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.)

Am 30.09.2020 um 07:33 schrieb Eric Sunshine:

Ok, it's kind of sad that as far as I understood, there is probably always only this heuristic about stripping ".git" because the main worktree path is not registered inside the .git dir or somewhere else. I mean you can technically name the git directory what ever you want and in that case how is that stripping than going to work? But of course when you do so, you probably need to set either GIT_DIR, or or use --git-dir

Also what I realized is, isn't the doc a bit inexact about GIT_DIR:

Shouldn't it read: GIT_DIR is the path of the .git folder. Location could mean its the parent folder? Hm...

Probably, --work-tree, GIT_WORK_TREE or core.worktree.

Thanks Eric! BR

On Wed, Sep 30, 2020 at 3:34 AM Gabriel Nützi <gnuetzi@gmail.com> wrote:

This is, of course, an artifact of Git's history. While Git itself is reasonably old at this point, linked worktrees are a relatively recent invention, and there had never been a reason to record the path of the main worktree anywhere. Also, not recording the path allows the project directory to be relocated easily if needed.

I don't think it's accurate to say that "you can technically name the git directory what ever you want". The only _blessed_ name for that directory is `.git/` if you expect any sort of automatic behavior regarding repository discovery and determination of the top level of a worktree.

Certainly, you're free to locate the repository elsewhere -- or name it something else -- but when you do so, you knowingly give up the convenience of the automatic behaviors, and instead have to rely upon --git-dir, GIT_DIR and --worktree, GIT_WORK_TREE, and core.worktree, which is why those exist.

(Rather than --git-dir, --git-work-tree and cousins, you could also place a "gitfile" named `.git` in the main worktree referencing the actual repository path, and by doing so regain all the automatic behaviors. Alternately, `git init --separate-git-dir` could set this up for you.)

At any rate, the above comments aside, as mentioned previously, a way forward might be to teach git-worktree to consult --work-tree, GIT_WORK_TREE, core.worktree when computing the path of the main worktree. The fact that it doesn't yet do so is merely an oversight, I think; one of the several such oversights during initial development, some of which have already been corrected.

That might indeed be an improvement. Perhaps submit a patch making this change?

On Wed, Sep 30, 2020 at 1:33 AM Eric Sunshine <sunshine@sunshineco.com> wrote:

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).

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

On Mon, Dec 7, 2020 at 2:28 AM Ganriel Nützi <gnuetzi@gmail.com> wrote:

I'm having trouble understanding your proposal. Secondary worktrees don't have a .git/ directory; instead they have a "gitfile" named .git which is just a pointer to the worktree's administrative directory within the repository (specifically, <repo>/worktrees/<id>/, where <repo> might be a bare repository or the .git/ directory of the main worktree).

So a secondary worktree's back-link is a pointer into the repository; it's not necessarily pointing at the main worktree, as you discovered and reported in the email which started this thread.

What I was suggesting was that it might be the case that the only way to solve this would be to store the location of the main worktree somewhere within <repo> in some file, and then `git worktree list` would consult that file to learn the location of the main worktree. This is complicated by the fact that that file would have to be updated automatically if the main worktree directory is ever moved. It also needs to be done in such a way that it is easy for other Git implementations to understand and not trip over.

So, it's certainly possible, but it's something which requires more thought, and there might be alternate and better solutions I'm overlooking.

On Wed, Dec 9, 2020 at 2:27 AM Eric Sunshine <sunshine@sunshineco.com> wrote:

Not that it matters because I don't do Git anymore. But when I was doing this I imagined unify main and secondary worktrees. When you switch from single to multiple worktrees, there is no main worktree anymore. The place that is main worktree still has your files, but it has the same status and treatment as any other worktree. And the repo is tucked away somewhere safe.

On Wed, Dec 9, 2020 at 4:31 AM Duy Nguyen <pclouds@gmail.com> wrote:

I had some vague thoughts along those lines, as well, but such a change is outside the scope of my limited time these days.

Superficially, the idea I expressed above, of storing the path of the main worktree in some file within the repository (let's say `.git/mainworktreepath`) doesn't seem like it should be too difficult (though I haven't really thought it through). And, if the main worktree does get moved, the file could be fixed up or kept up-to-date by the `git worktree repair` command.

(By the way, thanks for responding. It's nice to hear from you again after your long absence.)