From: Mark Levedahl <mlevedahl@gmail.com>
Date: Mon, 04 May 2026 15:13:33 GMT
Subject: Re: [PATCH v3 1/1] git-gui: handle missing worktree and separated gitdir
Message-ID: <7d5cf952-badb-4071-a0eb-af9443fa8b5b@gmail.com>
In-Reply-To: <73b99b54-1d39-45c1-bd06-26ac1008fddb@kdbg.org>



On 5/3/26 4:53 AM, Johannes Sixt wrote:
> I would not call the use of --is-bar-repository instead of
> --is-inside-git-dir an error, just a choice that has been made. In
> particular, when the startup directory is named '.git' and is not marked
> as bare, then its parent directory can very reasonably be taken as its
> worktree. (That's how things worked before --show-toplevel was used.) If
> the check is for --is-inside-git-dir, this treatment would be ruled out
> early.
>
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.)
> 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.

git-gui sets GIT_WORK_TREE and GIT_DIR at startup. GIT_DIR passes my simple tests, but
mishandles GIT_WORK_TREE.

I expect these two invocations to be equivalent, both starting git-gui in the worktree
'/some/path':

    GIT_WORK_TREE=/some/path git gui
    git -C /some/path gui

But, the GIT_WORK_TREE approach:
    works as I expect ONLY when the current directory is a valid worktree
    when started from a gitdir, uses that gitdir in conjunction with the requested worktree
    when started from an uncontrolled directory, shows the repository picker.

The git -C approach is indifferent to the current directory, of course.

GIT_WORK_TREE enters much too late in the process, and rather should handled first:
    if GIT_WORK_TREE is in the environment, cd to that first. Throw an error if that
directory is not a valid worktree.

I don't actually understand the use case of defining GIT_DIR or GIT_WORK_TREE to git gui,
and I wonder what other bugs are lurking... maybe the better approach is to just abort if
GIT_DIR or GIT_WORK_TREE are defined?

Mark