From: Mark Levedahl Date: Wed, 06 May 2026 11:27:59 GMT Subject: Re: [PATCH v3 1/1] git-gui: handle missing worktree and separated gitdir Message-ID: In-Reply-To: On 5/6/26 3:32 AM, Johannes Sixt wrote: >> Whether being in a gitdir is ok, or a worktree required, is of fundamental importance and >> is not explicitly checked now. This is my issue. (Whether the repo is bare, or embedded in >> a worktree, is relevant only when automatically fixing a user error.) > I don't quite follow what you a trying to say here. I played a bit more: A git repository (gitdir) can have config.bare true | false | not set git rev-parse --is-bare-repository tells you that whatever gitdir is discovered from the current directory has core.bare==true. This happens whether the call is from inside the gitdir, or in the parent dir of a gitdir named '.git', or in a directory containing a symlink or a gitfile link to the gitdir. This call never tells you what directory you are actually in. git rev-parse --is-inside-work-tree gives:     true - the call is made from a directory that is suported/supportable as a worktree of a gitdir.     false - the call is made from inside a gitdir, or from a directory linked to a to a gitdir with core.bare == true.     and error is thrown if no gitdir is discovered. I find --is-inside-work-tree a much better call to make early in setup.      true - full git-gui is ok,      false - blame/browser is ok (gitdir might have core.bare true)     error - no gitdir found, the repository picker should be called. So, the only need to test if the repo is marked bare is when looking for a possible worktree when git-gui was started inside the gitdir, or started in a directory linked to said gitdir, or GIT_DIR in the environment points to said gitdir: I consider all of this a user (or configuration) error, and there are many possible causes to explore to give useful feedback to the user. But, there are many ways to code this. I started down a path of using --is-inside-worktree, but in the end there are still a lot of corner cases to find. >>> But perhaps there is a simpler solution: Let's present an error if >>> --show-toplevel fails except in the case where the startup directory is >>> named '.git' (and is a valid Git repository) and is not bare (then the >>> worktree is the parent). I insist in this exception, because this >>> use-case was considered important in the past (87cd09f43e56 "git-gui: >>> work from the .git dir", 2010-01-23). >>> >>> -- Hannes >>> >> This would not fix gitk's blame / browse from a gitdir, and I don't really see a one or >> two line fix as being adequate. As you mentioned elsewhere, the problem on browser/blame is that _gitworktree is empty when no worktree is found, so GIT_WORK_TREE is exported to the environment as an empty variable. This cause is in a commit from 12 years ago:     3decb8e0ac ("git-gui: tolerate major version changes when comparing the git version", 2014-05-17) Prior to that commit and if not using git v1.7.x, an alternate branch of code not using git rev-parse was used for worktree discovery, and that code set _gitworktree = _gitdir when in a gitdir. The alternate code was removed more recently as it was unreachable from non-ancient git versions. The fix is to set _gitworktree to _gitdir before exporting GIT_WORK_TREE, or to just not export an empty GIT_WORK_TREE. Obviously, having GIT_WORK_TREE = GIT_DIR is asking for trouble, but perhaps is ok as git-gui is running in a read-only mode for browse/blame. My limited testing shows this works. Mark