lkml.org 
[lkml]   [2019]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] Documentation/process: hardcoded core.abbrev considered harmful!
Date
> -----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

\
 
 \ /
  Last update: 2019-01-15 20:45    [W:0.052 / U:0.956 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site