From: Johannes Sixt <j6t@kdbg.org>
Date: Tue, 02 Jun 2026 17:34:28 GMT
Subject: Re: [PATCH v3 00/12] Improve git gui operation without a worktree
Message-ID: <8515a482-9a08-4b0a-bd7c-385e1bda1a20@kdbg.org>
In-Reply-To: <20260531230225.126817-1-mlevedahl@gmail.com>

Am 01.06.26 um 01:02 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 to select a
>   worktree from a list and/or start a new repo+worktree: this dialog can
>   appear at unexpected times, masking useful error feedback on
>   configuration problems.
> 
> This patch series addresses the above issues, substantially rewriting
> the initial repository/worktree process to rely upon git rev-parse so
> that git's knowledge of access rules, repository configuration, and use
> of GIT_DIR / GIT_WORK_TREE (or git --gitdir / --work-tree) is used
> throughout, replacing code largely based upon what git did in 2008. This
> also means that git gui will naturally gain any new rules implmented in
> git-core.
> 
> With this, git-gui only exports GIT_WORK_TREE when non-empty.
> GIT_WORK_TREE is needed, and must be exported, if the user is overriding
> core.worktree in the git repository. But, GIT_WORK_TREE cannot be used
> to specify the lack of a worktree, so exporting an empty GIT_WORK_TREE
> is one of the problems fixed by this series.
> 
> v3 of this series addresses j6t's review of v2, with some reordering of
> patches (1 from j6t added, patch #8 moved to #1), adds another rewrite
> of the browser / blame parser that eliminates the notion of path before
> rev on the command line, blame works correctly with a user modified file
> in the worktree. Clarification is added on the need for GTI_WORK_TREE,
> and the logic in finding a worktree from the gitdir is simplified.
> 
> Johannes Sixt (1):
>   git-gui: remove unnecessary 'cd $_gitworktree' from do_gitk
> 
> Mark Levedahl (11):
>   git-gui: use HEAD as current branch when detached
>   git-gui: guard set/unset of GIT_DIR and GIT_WORK_TREE
>   git-gui: do not change global vars in choose_repository::pick
>   git-gui: use --absolute-git-dir
>   git-gui: use rev-parse exclusively to find a repository
>   git-gui: use git rev-parse for worktree discovery
>   git-gui: simplify [is_bare] to report if a worktree is known
>   git-gui: try harder to find worktree from gitdir
>   git-gui: allow specifying path '.' to the browser
>   git-gui: check browser/blame arguments carefully
>   git-gui: add gui and pick as explicit subcommands
> 
>  git-gui.sh                | 377 ++++++++++++++++++++++----------------
>  lib/choose_repository.tcl |  21 +--
>  2 files changed, 223 insertions(+), 175 deletions(-)

This round looks excellent! Thank you very much!

While queuing, I applied the small fixup below to 03/12.

-- Hannes

diff --git a/git-gui.sh b/git-gui.sh
index 933e72c9b255..15dd2b3a84cc 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2064,7 +2064,6 @@ proc incr_font_size {font {amt 1}} {
 
 proc do_gitk {revs {is_submodule false}} {
 	global current_diff_path file_states current_diff_side ui_index
-	global _gitworktree
 
 	# -- Always start gitk through whatever we were loaded with.  This
 	#    lets us bypass using shell process on Windows systems.