From: Shroom Moo <egg_mushroomcow@foxmail.com>
Date: Thu, 21 May 2026 05:02:59 GMT
Subject: Re: [PATCH v2 10/11] git-gui: adapt blame/browser parsing for bare operation
Message-ID: <tencent_407FE60B6954528497709B6CAD49018D120A@qq.com>
In-Reply-To: <20260520202411.108764-11-mlevedahl@gmail.com>

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