Re: [PATCH v3 1/1] git-gui: handle missing worktree and separated gitdir

[Johannes Sixt <j6t@kdbg.org>]

Am 02.05.26 um 23:51 schrieb Mark Levedahl:
> Two basic problems I see here are beyond the question of if (and when) git-gui should try
> to locate a worktree:
> 
> - git gui blame in a gitdir was apparently broken by the git repo commit 2d92ab32fd
> ("rev-parse: make --show-toplevel without a worktree an error", 2019-11-19). Prior to that
> commit, git gui would stay in the startup directory enabling only features that cannot
> modify the repository, and gitk could bring this view up in a gitdir. This doesn't work
> right now.

True, `blame` used to work in bare repositories, but is broken now.

> - git-gui's logic includes a conceptual error embodied in proc is_bare: is_bare uses $(git
> rev-parse --is-bare-repository) but what we need is $(git rev-parse --is-inside-git-dir),
> and these are not synonyms.
> It does not matter whether a worktree exists that points at the gitdir, and as discussed
> before, main worktrees can easily exist that we cannot locate from the gitdir. At best,
> is_bare is a guess.
> So, is_bare should be replaced by is_inside_gitdir, and we should also have
> is_inside_worktree. These are mutually exclusive, though both can be false.

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.


> My current idea of an improved startup flow enables features only at the end:
> 
> 1) If not in a gitdir or worktree, 
>     1a)   if git gui's subcommand is not 'gui', abort with an error (citool, browser, or
> blame invocations carry information specific to a gitdir/worktree). 
>     1b)   otherwise, invoke repository_chooser, which either aborts, or changes directory
> to a worktree.
> 
> -- we are now in a gitdir or a worktree, and this may or may not be the startup directory.
> 
> 2) Look at the combination of git gui subcommand and directory type (worktree / gitdir) to
> decide to continue.
>     2a) blame / browser are ok in either directory type.
>     2b) citool requires a specific worktree, which should have been the initial startup
> directory. Abort if not.
>     2b) gui requires a worktree. Abort if not (my recommendation), or offer to find (or
> automatically find) a worktree.
> 
> 3) Change directory to the top level of of the directory_type (git rev-parse knows
> toplevel of a worktree, different code is needed for a gitdir).
> 
> 4) Enable features based upon subcommand and directory type.
> 
> There are 12 combinations of initial directory type (gitdir, worktree, neither) and
> subcommand (gui, blame, browser, citool) to consider, with a lot of duplicated code
> amongst the 12 cases. So, obviously, steps 1 and 2 can be convolved in many ways that are
> different than what I wrote above.
So true.

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