From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751005AbdEMERs (ORCPT ); Sat, 13 May 2017 00:17:48 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:47278 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750822AbdEMERq (ORCPT ); Sat, 13 May 2017 00:17:46 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Rob Landley Cc: Thomas Gleixner , Michael Ellerman , Linus Torvalds , Al Viro , Oleg Nesterov , Linux Kernel Mailing List References: <87k25ol41u.fsf@xmission.com> <87h90rj2ub.fsf@concordia.ellerman.id.au> <1de8bc32-ebac-141a-080a-ef1c5a149904@landley.net> <87r2zuc08d.fsf@concordia.ellerman.id.au> <87shka2kxn.fsf@xmission.com> <1638b34f-742d-d718-6ab2-cfed861278e4@landley.net> Date: Fri, 12 May 2017 23:11:12 -0500 In-Reply-To: <1638b34f-742d-d718-6ab2-cfed861278e4@landley.net> (Rob Landley's message of "Fri, 12 May 2017 11:30:37 -0500") Message-ID: <87tw4ptmzj.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1d9OUp-0005Ah-JS;;;mid=<87tw4ptmzj.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.121.81.159;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+tSQwgILsEkD2S4h1lYC/s0CSCu6eaghw= X-SA-Exim-Connect-IP: 97.121.81.159 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Rob Landley X-Spam-Relay-Country: X-Spam-Timing: total 5663 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.1 (0.1%), b_tie_ro: 2.1 (0.0%), parse: 1.41 (0.0%), extract_message_metadata: 39 (0.7%), get_uri_detail_list: 5 (0.1%), tests_pri_-1000: 15 (0.3%), tests_pri_-950: 2.1 (0.0%), tests_pri_-900: 1.61 (0.0%), tests_pri_-400: 39 (0.7%), check_bayes: 37 (0.7%), b_tokenize: 15 (0.3%), b_tok_get_all: 9 (0.2%), b_comp_prob: 6 (0.1%), b_tok_touch_all: 4.1 (0.1%), b_finish: 0.84 (0.0%), tests_pri_0: 572 (10.1%), check_dkim_signature: 0.87 (0.0%), check_dkim_adsp: 4.4 (0.1%), tests_pri_500: 4984 (88.0%), poll_dns_idle: 4976 (87.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: Is there an recommended way to refer to bitkeepr commits? X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rob Landley writes: > On 05/12/2017 09:45 AM, Eric W. Biederman wrote: >> Thomas Gleixner 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