Re: [PATCH v2 10/11] git-gui: adapt blame/browser parsing for bare operation

[Mark Levedahl <mlevedahl@gmail.com>]

On 5/21/26 1:02 AM, Shroom Moo wrote:
> On 5/21/26 4:24 AM, Mark Levedahl wrote: 
>> +proc find_path_type {head path} {
>> +	if {$path eq {./}} {
>> +		# the root-tree exists in every rev, ls-tree gives data on the contents,
>> +		# not the type of tree itself. So, if the rev exists, return {tree}
>> +		if {[catch {set objtype [git ls-tree $head]}]} {
>> +			set objtype {}
>> +		} else {
>> +			set objtype {tree}
>> +		}
>> +	} else {
>> +		# test that the path exists in head, ls-tree gives info on the path only
>> +		if {[catch {set objtype [git ls-tree {--format=%(objecttype)} $head $path]}]} {
>> +			set objtype {}
>> +		}
>> +	}
>> +	return $objtype
>> +}
> In v1, argument parsing relied on file exists within the worktree to 
> determine if a path existed, without using ls-tree. In v2, the use of 
> git ls-tree seems to actually be intended to list directory contents, 
> rather than querying the type of the path itself. 
>
> If $path is a directory (a tree object), git ls-tree outputs the 
> object type for every entry within that directory, one per line. 
>
> The variable objtype is assigned a multi-line string. When compared 
> against "tree", the match fails, causing the function to return an 
> empty string, which subsequently leads to an error. We can change to 
> "git cat-file -t" or similiar approaches. 
>
> Shroom
>
git ls-tree $rev $path --format='%(objecttype)' gives the type of the object at $path in
$rev, or an error. The types returned are "tree" for a directory, "blob" for a file. So
this gives definitive information if the object desired exists in the given rev, and is of
the right type. (We don't care about commits and tags, those cannot be blamed or browsed).

git-lstree $rev $dirname/  lists all of the objects in the directory, while git-lstree
$rev $dirname (no trailing /) gives info on the directory itself. There is no name for the
root directory itself, all of its contents are listed. That is why the root './' is
special case.

Asking the worktree that is on version 33 about whether frotz is a directory in version 2
is just asking for trouble, at best the worktree is authoritative for the checked out
version, but even then there can be uncommitted changed. In the root of git-gui, I get

/git-gui.sh browser gitgui-0.9.0 Makefile
'Makefile' is not a directory in rev 'gitgui-0.9.0'

so the types of objects are being checked.

Mark