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  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:   Fri, 12 May 2017 23:11:12 -0500
From: (Eric W. Biederman)
To:     Rob Landley <>
Cc:     Thomas Gleixner <>,
        Michael Ellerman <>,
        Linus Torvalds <>,
        Al Viro <>,
        Oleg Nesterov <>,
        Linux Kernel Mailing List <>
Subject: Re: Is there an recommended way to refer to bitkeepr commits?

Rob Landley <> writes:

> On 05/12/2017 09:45 AM, Eric W. Biederman wrote:
>> Thomas Gleixner <> writes:
>>> On Fri, 12 May 2017, Michael Ellerman wrote:
>>>>   Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] linux-2.5.66-signal-cleanup.patch")
>>>> In your tree that is c3c107051660 ("[PATCH] linux-2.5.66-signal-cleanup.patch"),
>>>> but you don't have the 3e8e57a1JvR25MkFRNzoz85l2Gzccg revision recorded
>>>> anywhere that I can see.
>>> That's correct. I did not include the BK revisions when I imported the
>>> commits into the history git. I did not see any reason to do so. I still
>>> have no idea what the value would have been or why anyone wants to
>>> reference them at all.
>> Thomas your import seems to be significantly better than the one I got
>> my hands on years ago.
>> I just know that if were to do something similar today we would really
>> want to preserve the existing git sha1 hashes somewhere because we
>> refer to commits everywhere in the code.
> Which is why the tree uses "git
> graft", so the git commit numbers are the same.
> As Yoann Padioleau said:
>> It's built from 3 other git repositories:
>>  - the one from Dave Jones from 0.01 to 2.4.0,
>>  - the one from tglx from 2.4.0 to 2.6.12,
>>  - the one from Linus Torvalds from 2.6.12 to now.
> And the hashes in his tree were the same as in each of those trees, all
> three of which are on If you "git pull" the fullhist
> tree to current, it still uses the same hashes today. (I think you can
> still reproduce it localy using his scripts, which I mirrored. You'll
> have to manually re-tag those old commits from last message, and reset
> the "upstream" to pull current from.)

Which leaves me perplexed.  The hashes from tglx's current tree:
on and the hashes in your full history tree differ.
Given that they are in theory the same tree this distrubs me.

Case in point in the commit connected to:
"[PATCH] linux-2.5.66-signal-cleanup.patch"
in tglx's tree is:       da334d91ff7001d234863fc7692de1ff90bed57a
in the fullhist tree is: c3c107051660455a3e1ea3bde0278a75a0dc11e7

>> Compare the quotes lines above with what I have below.  Every tree
>> appears to have a different identifier.
> The commits in the fullhist tree have been stable since at least
> which was June 6, 2008. It's derived
> from earlier trees with the same commits, and kept those commit
> hashes.

*scratches my head*

Something appears to have changed somewhere.


Powered by blists - more mailing lists