Messages in this thread | | | Subject | Re: Is there an recommended way to refer to bitkeepr commits? | From | Rob Landley <> | Date | Fri, 12 May 2017 11:30:37 -0500 |
| |
On 05/12/2017 09:45 AM, Eric W. Biederman wrote: > Thomas Gleixner <tglx@linutronix.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.)
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
| |