Re: [PATCH v2 0/2] object-name: fix resolution of object names containing curly braces

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 4, 2025, 14:35 UTC
Message-ID: <xmqqed1i4pga.fsf@gitster.g>
In-Reply-To: <pull.1844.v2.git.1735949870.gitgitgadget@gmail.com>

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 10 quoted lines

>  * Added a second patch for another bug discovered by the same reporter,
>    where branch:path/to/file/named/major-gaffed is interpreted as a request
>    for a commit (namely affed) rather than a blob. (At least, assuming
>    commit affed exists)
>
> The second patch has some backward compatibility concerns. People used to be
> able to do e.g. git show ${garbage}-g${hash}. I tightened it to
> ${valid_refname}-${number}-g${hash}, but do we want to allow e.g.
> ${valid_refname}-g${hash} (allowing the count to be omitted) or maybe even
> allow a subset of invalid refnames?

My take on it is that it is an absolute no-no if we require that ${valid_refname} exists locally, and it is still iffy if we checked ${valid_refname} with check_format() (because the definition of validity can change over time, and we would not know the rules that were valid back when the reference to the commit was written).

Otherwise a tightened rule would make "${garbage}-g${hash}" less useful to copy-and-paste from a text file to command line.

In general what would we do if a string can be interpreted in multiple ways in _different_ parts of the object-name codepaths. We all know that "affed" would trigger the "ambiguous object name" error if there are more than one object whose object name begins with "affed", but if "${garbage}-gaffed" can be interpreted as the name of an object whose object name begins with "affed" and also can be interpreted as the name of another object that sits at a path that ends with "-gaffed" in some tree object, regardless of how the leading part "${garbage}" looks like, it would be desirable if we declared such a string as "ambiguous" the same way.