linux-kernel - Re: Is there an recommended way to refer to bitkeepr commits?

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:   Fri, 12 May 2017 23:11:12 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Rob Landley <rob@...dley.net>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Michael Ellerman <mpe@...erman.id.au>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Oleg Nesterov <oleg@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Is there an recommended way to refer to bitkeepr commits?

Rob Landley <rob@...dley.net> writes:

> On 05/12/2017 09:45 AM, Eric W. Biederman wrote:
>> Thomas Gleixner <tglx@...utronix.de> 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 https://landley.net/kdocs/fullhist 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 git.kernel.org. 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:
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
on kernel.org 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
> https://lwn.net/Articles/285366/ 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.

Eric