linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
	"Jacob Keller" <jacob.e.keller@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jeff Kirsher" <jeffrey.t.kirsher@intel.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: [PATCH] Documentation/process: hardcoded core.abbrev considered harmful!
Date: Thu, 20 Dec 2018 01:01:12 +0100	[thread overview]
Message-ID: <20181220000112.24891-1-avarab@gmail.com> (raw)
In-Reply-To: <1396949135-27122-1-git-send-email-jeffrey.t.kirsher@intel.com>

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 <avarab@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


  reply	other threads:[~2018-12-20  0:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-08  9:25 [PATCH] doc: update SubmittingPatches about the Fixes tag Jeff Kirsher
2018-12-20  0:01 ` Ævar Arnfjörð Bjarmason [this message]
2019-01-15 19:41   ` [PATCH] Documentation/process: hardcoded core.abbrev considered harmful! Joe Perches
2019-01-15 19:44     ` Keller, Jacob E
2019-01-30  0:18   ` Stephen Rothwell
2019-01-30 23:36     ` Frank Rowand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181220000112.24891-1-avarab@gmail.com \
    --to=avarab@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).