Messages in this thread | | | From | "Keller, Jacob E" <> | Subject | RE: [PATCH] Documentation/process: hardcoded core.abbrev considered harmful! | Date | Tue, 15 Jan 2019 19:44:54 +0000 |
| |
> -----Original Message----- > From: Joe Perches [mailto:golf@perches.com] > Sent: Tuesday, January 15, 2019 11:41 AM > To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>; Linus Torvalds <torvalds@linux- > foundation.org> > Cc: linux-kernel@vger.kernel.org; Keller, Jacob E <jacob.e.keller@intel.com>; Andrew > Morton <akpm@linux-foundation.org>; Kirsher, Jeffrey T > <jeffrey.t.kirsher@intel.com> > Subject: Re: [PATCH] Documentation/process: hardcoded core.abbrev considered > harmful! > > On Thu, 2018-12-20 at 01:01 +0100, Ævar Arnfjörð Bjarmason wrote: > > Stop recommending that core.abbrev=12 be hardcoded when referring to > > kernel commits, and instead rely on the git's default abbreviation. > > Nothing happened to this patch and there was no reply to > it as far as I can tell. > > This may be sensible for future git versions, but perhaps > there should be a different abbrev control added and the > kernel should enable that. > > > 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. > > Will '$ git config --get core.abbrev' return a specific > number in that case? > > (not +1 and not blank as current if unspecified) >
I wouldn't think so. There might need to be some sort of plumbing command added to obtain this information.
Might be worth pointing that out on the git-devel mailing list.
Thanks, Jake
| |