Stop recommending that core.abbrev=12 be hardcoded when referring to
kernel commits, and instead rely on the git's default abbreviation.
Hardcoding this at "12" was done in
8401aa1f5997 ("Documentation/SubmittingPatches: describe the Fixes:
tag", 2014-06-06), back then Linus's git/git@e6c587c733 ("abbrev: auto
size the default abbreviation", 2016-09-30) had not yet landed, and
the default abbreviation was "7".
At the time linux.git had around 3.5 million objects, so if the auto
sizing had been in effect "11" would have been picked. Now "12" is
what we pick by default anyway.
More importantly, we'll roll over to "13" at around 16 million
objects, which given the growth rate isn't that far off. At that point
this documentation will be worse than the default.
Let's just stop doing this. Git versions as of 2.11 released over 2
years ago use the auto-sizing, and it seems like a fair assumption
that kernel developers use a fairly recent git version.
Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com>
---
As an aside I have upcoming git.git patches so you'll be able to set
core.abbbrev to e.g. +1 to get "13" now, "14" when it rolls over at
~16 million etc. Maybe that'll be a good fit for projects like
linux.git that want more future-proof abbreviated SHAs than most.
Documentation/process/submitting-patches.rst | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/process/submitting-patches.rst
b/Documentation/process/submitting-patches.rst
index c0917107b90a..faf661f58cb1 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -189,8 +189,6 @@ the SHA-1 ID, and the one line summary. For example::
The following ``git config`` settings can be used to add a pretty format for
outputting the above style in the ``git log`` or ``git show`` commands::
- [core]
- abbrev = 12
[pretty]
fixes = Fixes: %h (\"%s\")
--
2.20.1.415.g653613c723
