On Thu, Dec 05, 2024 at 11:19:18AM -0800, Linus Torvalds wrote:
> Why do I care? Because long git commit IDs are actually detrimental to
> legibility. I try to make commit messages legible, and that very much
> is the *point* of the short format. It's for people, not machinery.
>
> Yes, the basic git machinery doesn't do object type disambiguation
> (and if you do "git show", you can give it blob IDs etc, so git itself
> may not know about the proper type to use disambiguate at all). And
> git also doesn't know about the whole "we also put the first line of
> the commit message" thing.
>
> But honestly, I'm claiming that something like
>
> Fixes: 48bcda684823 ("tracing: Remove definition of trace_*_rcuidle()")
I have wondered about using a different encoding for the sha1.
Classic Ascii85 encoding is no good; it uses characters like '"\<
which interact poorly with every shell. RFC1924 is somewhat better,
but still uses characters that interact poorly with shell.
Base36 (ie 0-9a-z) would take 10 characters to represent as many bits
as 12 characters in base16. Base62 (0-9a-zA-Z) gives us 8 characters
to represent _almost_ 48 bits. We could do Base64 (RFC 4648) which
uses + and /, and is common enough. Good enough to be worth the
additional complexity?
