GIT_DIR output from git worktree list

GIT_DIR output from git worktree list

[Gabriel Nützi]

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

Re: GIT_DIR output from git worktree list

[Eric Sunshine]

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

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

Re: GIT_DIR output from git worktree list

[Gabriel Nützi]

Am 30.09.2020 um 07:33 schrieb Eric Sunshine:

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

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:

> GIT_DIR is the location of the .git folder.

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

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

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

Thanks Eric!
BR

Re: GIT_DIR output from git worktree list

[Eric Sunshine]

On Wed, Sep 30, 2020 at 3:34 AM Gabriel Nützi <gnuetzi@gmail.com> wrote:
> Am 30.09.2020 um 07:33 schrieb Eric Sunshine:
> > 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. [...]
>
> 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.

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

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.

> Also what I realized is, isn't the doc a bit inexact about GIT_DIR:
>
> > GIT_DIR is the location of the .git folder.
>
> Shouldn't it read: GIT_DIR is the path of the .git folder. Location
> could mean its the parent folder? Hm...

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

Re: GIT_DIR output from git worktree list

[Eric Sunshine]

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

Re: GIT_DIR output from git worktree list

[Ganriel Nützi]

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

Re: GIT_DIR output from git worktree list

[Eric Sunshine]

On Mon, Dec 7, 2020 at 2:28 AM Ganriel Nützi <gnuetzi@gmail.com> wrote:
> 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?)

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.

Re: GIT_DIR output from git worktree list

[Duy Nguyen]

On Wed, Dec 9, 2020 at 2:27 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> 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.

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

Re: GIT_DIR output from git worktree list

[Eric Sunshine]

On Wed, Dec 9, 2020 at 4:31 AM Duy Nguyen <pclouds@gmail.com> wrote:
> On Wed, Dec 9, 2020 at 2:27 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > 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.
>
> 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.

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