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

[Rob Landley]

On 05/12/2017 09:45 AM, Eric W. Biederman wrote:
> Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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.)

Last I checked I couldn't just "git push" the fullhist tree to
git.kernel.org because git graft didn't propagate right. I had to start
people from a tarball. Local clones doing the hardlink thing worked fine
though. (Maybe that's changed?)

> So I was imagining that bitkeeper would be similar.

When Larry flounced and people lost access to the bitkeeper tool they
lost access to read the old data, so what the bitkeeper numbers were
became irrelevant. That's why nobody's cared before now.

You're looking for a consistent way to refer to old commits, even using
bitkeeper numbers wouldn't fully solve that problem (it only goes back
to 2.4). Between the dave jones and tglx trees, there's complete
coverage back to 0.0.1. Yoann stitched them together, and I've kept a
current version. I used to host it on kernel.org/doc until
http://lkml.iu.edu/hypermail/linux/kernel/1411.3/04693.html happened,
they've since deleted it but it's GPL so anybody who wants to host a
mirror... :)

I'm traveling and not downloading a gigabyte through my phone tether
(darn tmobile 4 gig monthly tethering limit) but the date on the
https://landley.net/kdocs/local/linux-fullhist.tar.bz2
tarball is February 2016 so I'm pretty sure that's 4.0 with the old
major releases tagged (ala last email). Anybody who wants to mirror it
somewhere more official (and presumably .xz instead of .bz2) is welcome to.

(I would if I still had rsync access to kernel.org/doc, but alas I can't
even get them to link kernel.org/doc/Documentation from the page above
it. It used to, they accidentally deleted it, and nobody maintains the
page anymore...)

> Especially since the copy of the bitkeeper
> import into git had appened to each commit a BKrev which I presume
> tacked back to the original source.
> 
> If everyone who had imported the bitkeepr tree had done that it would
> not have mattered which bitkeeper import you were using they would all
> share a common identifier for commits.  With that absent the robustness
> we have to allow looking things up in an alternate tree lies solely
> with the one line patch description.
> 
> 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.

> Below is what I wound up doing, and have queued for the next merge
> window.  Comments?

I've bisected or used the "git annotate... git annotate HASH^1... git
annotate NEXTHASH^1..." peeling trick back to some really old commits
over the years, which I've then referred to by submitter and date if it
wasn't in the current git tree.

I'll happily give people hashes out of the fullhist tree if they ask,
but haven't assumed they're using it. But if you're looking for an
existing standard, this exists and predates my use of it.

> Eric

Rob