On 5/23/26 10:06 AM, Johannes Sixt wrote:

I tried to come up with a situation where we end up here, but couldn't.
When would this happen? If it actually can't happen, I would prefer to
spawn fewer git processes and just take the result of 'file dirname'.

If the code must remain, can we please rename one of gitdir_parent or
parent_gitdir?

There are some odd cases I've seen, mostly driven by network file systems (using Samba or
NFS or ...) that don't behave as POSIX. Perhaps that is reasonably out of scope. The more
I think about this, I'll delete that part.

Symlinks can create odd cases:

Consider /tmp/main  and  /tmp/worktree. The latter has a .git entry that is a symlink to
/tmp/main.git. git rev-parse --absolute-git-dir shows
    in dir /tmp/worktree/.git           /tmp/main.git
So, git-gui would start in /tmp/main, and not in /tmp/worktree.

If using git new-workdir (which is still in the wild), this creates a .git dir with
symlinks to all the subdirs. Now git rev-parse reports
   in dir /tmp/worktree.git          /tmp/worktree/.git
   in dir /tmp/worktree/.git/logs   /tmp/main/.git
So, as long as this is started in the top level of .git, it's ok.

While the shell understands we descended into a symlink and reports pwd does not
de-referencing the symlink, tcl always dereferences the symlinks. So, any ability to
contain this behavior is very likely system and shell dependent.

So, in summary, I'll probably simplify the check to just --show-toplevel run in the dir
above .git.


Mark