RE: [PATCH] Documentation/process: hardcoded core.abbrev considered harmful!

[Keller, Jacob E]

> -----Original Message-----
> From: Joe Perches [mailto:golf@xxxxxxxxxxx]
> Sent: Tuesday, January 15, 2019 11:41 AM
> To: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>; Linus Torvalds <torvalds@linux-
> foundation.org>
> Cc: linux-kernel@xxxxxxxxxxxxxxx; Keller, Jacob E <jacob.e.keller@xxxxxxxxx>; Andrew
> Morton <akpm@xxxxxxxxxxxxxxxxxxxx>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@xxxxxxxxx>
> 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