> -----Original Message----- > From: Joe Perches [mailto:[email protected]] > Sent: Tuesday, January 15, 2019 11:41 AM > To: Ævar Arnfjörð Bjarmason <[email protected]>; Linus Torvalds > <torvalds@linux- > foundation.org> > Cc: [email protected]; Keller, Jacob E <[email protected]>; > Andrew > Morton <[email protected]>; Kirsher, Jeffrey T > <[email protected]> > 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
