From: Johannes Sixt <j6t@kdbg.org>
Date: Sat, 16 May 2026 08:28:58 GMT
Subject: Re: [PATCH v1 00/11] Improve git gui operation without a worktree
Message-ID: <c5147296-06e1-4f7d-8f4f-f424e26e5b13@kdbg.org>
In-Reply-To: <20260514143322.865587-1-mlevedahl@gmail.com>

Am 14.05.26 um 16:33 schrieb Mark Levedahl:
> git gui has a number of inter-related problems that result in problems
> during startup from anything but a checked out worktree pointing at a
> valid git repository. Some of the symptoms are:
> - blame / browser subcommands, and launching gitk, are intended to be
>   useful without a worktree, but fail to work.
> - unlike git, git-gui is supposed to use the parent directory as a
>   worktree if started from the .git subdirectory in the very common
>   single worktree + embedded git repository format. This does not
>   work.
> - git-gui includes a repository picker allowing a user select a worktree
>   from a list and/or start a new repo+worktree: this dialog appears at
>   unexpected times, masking useful error feedback on configuration
>   problems.
> 
> This patch series addresses the above issues, substantially rewriting
> the blame / browser command line process, the initial repository and
> worktree discovery processes, and using git rev-parse when possible to
> handle repository / worktree discovery including any specification of
> GIT_DIR or GIT_WORK_TREE to reduce the future likelihood of conflict
> with command line git. This also allows explicit user control to avoid
> the repository picker masking a configuration error.

OK. Overall, this goes in the right direction. There are still open
questions and potential problems with this implementation. We also
disagree in a few details; see my comments on the patches.

> 
> Note: I question why git-gui ever exports GIT_WORK_TREE. If it is not
> empty, that is the current directory when startup is complete and any
> git command will use the current directory as the worktree.

I fully agree with this.

> If empty,
> there is no worktree and the current directory should be (and after this
> series, is) at the toplevel of the gitdir: again, there is nothing to
> communicate to another process.

Here I disagree. We should not need to change directory if no working
tree was found.

> If a process being launched needs a
> different worktree, that should be the startup directory given to the
> process without changing git-gui's current directory.

I haven't thought this through, but this sounds very reasonable.

> 
> Mark Levedahl (11):
>   git-gui: allow specifying path '.' to the browser
>   git-gui: refactor browser / blame argument parsing
>   git-gui: guard set/unset of GIT_DIR and GIT_WORK_TREE
>   git-gui: put choose_repository::pick in a proc
>   git-gui: use --absolute-git-dir
>   git gui: GIT_DIR / GIT_WORK_TREE make any discovery error fatal
>   git-gui: use rev-parse exclusively to find a repository
>   git-gui: simplify [is_bare] to report if a worktree is known
>   git-gui: support using repository parent dir as a worktree
>   git-gui: improve worktree discovery
>   git-gui: add gui and pick as explicit subcommands
> 
>  git-gui.sh | 276 ++++++++++++++++++++++++++---------------------------
>  1 file changed, 135 insertions(+), 141 deletions(-)
> 

-- Hannes