[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: GIT_DIR output from git worktree list
From:       Eric Sunshine <sunshine () sunshineco ! com>
Date:       2020-09-30 20:35:31
Message-ID: CAPig+cSzVVdiH62Gc-ww56OFfPh4-2+3_paWEJf085TgC=nNvg () mail ! gmail ! com
[Download RAW message or body]

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?
[prev in list] [next in list] [prev in thread] [next in thread]