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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Jan 2019 19:44:54 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Joe Perches <golf@...ches.com>,
        Ævar Arnfjörð Bjarmason <avarab@...il.com>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: RE: [PATCH] Documentation/process: hardcoded core.abbrev considered
 harmful!

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