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 09:46:42 -0700
From:   Linus Torvalds <>
To:     Thomas Gleixner <>
Cc:     Michael Ellerman <>,
        Rob Landley <>,
        "Eric W. Biederman" <>,
        Al Viro <>,
        Oleg Nesterov <>,
        Linux Kernel Mailing List <>
Subject: Re: Is there an recommended way to refer to bitkeepr commits?

On Fri, May 12, 2017 at 12:43 AM, Thomas Gleixner <> wrote:
> 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.

The bitkeeper hashed revision numbers were almost entirely useless, to
the point where most BK users never really knew about them.

The revision numbers that people *saw* were the nasty horribly
sequential-tree ones that are fundamentally broken, and that change
when you merge (eg things like ""). That's what people
actually *used*, and saw in the logs, and were aware of. People used
them too much, in fact, exactly because people who came from other
environments thought that they were the revision numbers, and couldn't
understand that they weren't stable.

Nobody ever used the "true" hashes, except in scripts.

So exposing them would have been ridiculous. Even most BK users would
just have been confused by the line noise.


Powered by blists - more mailing lists