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

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Rob Landley <rob@landley.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Oleg Nesterov <oleg@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Is there an recommended way to refer to bitkeepr commits?
Date: Fri, 12 May 2017 09:46:42 -0700	[thread overview]
Message-ID: <CA+55aFyF0-b8dty38r6RohE=hDT2t2rO0byzUc+-5u-8fPFj+A@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1705120941060.1800@nanos>

On Fri, May 12, 2017 at 12:43 AM, Thomas Gleixner <tglx@linutronix.de> 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 "1.56.3.2"). 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.

                   Linus