linux-kernel - Re: [PATCH v2 2/2] Increase minimum git commit ID abbreviation to 16 characters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z12sScjRHpB1d0nO@casper.infradead.org>
Date: Sat, 14 Dec 2024 16:03:21 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>,
	Dwaipayan Ray <dwaipayanray1@...il.com>,
	Lukas Bulwahn <lukas.bulwahn@...il.com>,
	Joe Perches <joe@...ches.com>, Jonathan Corbet <corbet@....net>,
	Thorsten Leemhuis <linux@...mhuis.info>,
	Andy Whitcroft <apw@...onical.com>,
	Niklas Söderlund <niklas.soderlund@...igine.com>,
	Simon Horman <horms@...nel.org>, Conor Dooley <conor@...nel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Junio C Hamano <gitster@...ox.com>, workflows@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] Increase minimum git commit ID abbreviation to 16
 characters

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?