From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753771AbdEJW5D (ORCPT ); Wed, 10 May 2017 18:57:03 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:47454 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbdEJW5B (ORCPT ); Wed, 10 May 2017 18:57:01 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Al Viro , Thomas Gleixner , Oleg Nesterov , Date: Wed, 10 May 2017 17:04:44 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) X-From-Line: nobody Wed May 10 17:04:50 2017 Message-ID: <87k25ol41u.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1d8aXS-0006MC-9n;;;mid=<87k25ol41u.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.121.81.159;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18UHsqLk4tELmFCqkNvPt6GmPgeo1rLlaQ= 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.0 TVD_RCVD_IP Message was received from an IP address * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 1189 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 2.8 (0.2%), b_tie_ro: 1.93 (0.2%), parse: 0.86 (0.1%), extract_message_metadata: 3.2 (0.3%), get_uri_detail_list: 1.45 (0.1%), tests_pri_-1000: 3.6 (0.3%), tests_pri_-950: 1.73 (0.1%), tests_pri_-900: 1.51 (0.1%), tests_pri_-400: 19 (1.6%), check_bayes: 18 (1.5%), b_tokenize: 5 (0.5%), b_tok_get_all: 6 (0.5%), b_comp_prob: 2.1 (0.2%), b_tok_touch_all: 2.4 (0.2%), b_finish: 0.56 (0.0%), tests_pri_0: 1143 (96.1%), check_dkim_signature: 0.53 (0.0%), check_dkim_adsp: 3.2 (0.3%), tests_pri_500: 6 (0.5%), rewrite_mail: 0.00 (0.0%) Subject: 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 (Apologies resent as I forgot to include linux-kernel when I sent this the first time) I am in the process of digging through the intersection of threads, signals, ptrace, and exec and I am encountering bugs that predate 2.6.12-rc2 the first version in our current git tree. I am trying to figure out what to put in the fixes tag so that someone else can find the commits. I have an old tree that appears to be no longer available on kernel.org that has all of the commits from the bit keeper era as well as the annotations indicating the bit keeper revisions those commits came from. Thomas Gleixner appears to have a tree with all of those same commits except with the BKrev tags stripped out. While reading through the post 2.6.12-rc2 commits I ran into a commit from I think Linus that references what I believe was a pre 2.6.12-rc2 with what looked like a truncated sha1 hash. There title of the commit/patch was no included and the sha1 was not in any tree that I have so I didn't know how to follow that reference. I wish I had saved off which commit that was so I could make this description more concrete. I was thinking of referring to the old commit that was broken as: Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] linux-2.5.66-signal-cleanup.patch") With no trees that have a BKrev in them publicly available it doesn't look like anyone will be able to find that code. It use a git sha1 hash we would need a standard tree that we can reference and we don't appear to have that either. Is there any plan or standard recommendation on how handle bitkeeper era commits? Was there something sane and it was not properly restored after the kernel.org break-in? Eric