On Wed, Sep 30, 2020 at 3:34 AM Gabriel Nützi <gnuetzi@xxxxxxxxx> 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?
