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

"Elijah Newren via GitGitGadget" [off-list ref] writes:

 * 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.