Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes:
> Change the revision parsing logic to match ^{commit}, ^{tree}, ^{blob}
> etc. case-insensitively.
>
> Before this change supplying anything except the lower-case forms
> emits an "unknown revision or path not in the working tree"
> error. This change makes upper-case & mixed-case versions equivalent
> to the lower-case versions.
>
> The rationale for this change is the same as for making @{upstream}
> and related suffixes case-insensitive in "rev-parse: match
> @{upstream}, @{u} and @{push} case-insensitively", but unlike those
> suffixes this change introduces the potential confusion of accepting
> TREE or BLOB here, but not as an argument to e.g. "cat-file -t <type>"
> or "hash-object -t <type>".
It's not "potential confusion". This closes the door for us to
introduce "TREE" as a separate object type in the future.
If we agree to make a declaration that all typenames are officially
spelled in lowercase [*1*] and at the UI level we accept typenames
spelled in any case, then we can adopt this change (and then we need
to update "cat-file -t" etc. to match it).
I do not at all mind to see if the list concensus is to make such a
declaration and permanently close the door for typenames that are
not lowercase, and after seeing such a concensus I'd gladly
appreciate this patch, but I do not want to see a change like this
that decides the future of the system, pretending as an innocuous
change, sneaked in without making sure that everybody is aware of
its implications.
[Footnote]
*1* "officially spelled in lowercase" is necessary to avoid
confusion, because we are not making typenames case insensitive,
allowing an object whose raw-bytes in its loose object
representation before deflating begins with "COMMIT" and take it
as an object of <commit> type. Instead, such a declaration will
make such an object an invalid one (as opposed to "object of an
unknown type", as it currently is).
