From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79683 invoked by alias); 17 Mar 2016 10:34:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 79667 invoked by uid 89); 17 Mar 2016 10:34:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=twelve, Joel, yells, five X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 17 Mar 2016 10:34:45 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 6F1158E25F; Thu, 17 Mar 2016 10:34:44 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2HAYh7X021353; Thu, 17 Mar 2016 06:34:43 -0400 Subject: Re: [patch for 7.11] btrace: fix PR gdb/19829 To: "Metzger, Markus T" , "brobecker@adacore.com" References: <1458200914-1638-1-git-send-email-markus.t.metzger@intel.com> <56EA81D5.10007@redhat.com> Cc: "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: <56EA8843.2000502@redhat.com> Date: Thu, 17 Mar 2016 10:34:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00304.txt.bz2 On 03/17/2016 10:22 AM, Metzger, Markus T wrote: >> -----Original Message----- >> From: Pedro Alves [mailto:palves@redhat.com] >> Sent: Thursday, March 17, 2016 11:07 AM >> To: Metzger, Markus T ; >> brobecker@adacore.com >> Cc: gdb-patches@sourceware.org >> Subject: Re: [patch for 7.11] btrace: fix PR gdb/19829 >> >> On 03/17/2016 07:48 AM, Markus Metzger wrote: >>> This is a backport of >> >> It's fine with me to put this in the branch. > > Should I wait for Joel's OK, as well? Joel usually defers deciding whether a patch is safe for the branch to the maintainer that originally approved it, and I do think it is safe. So I believe you're good to go. Worse that can happen is Joel yells at me, and we'll revert. :-) >> (I'd have cherry picked the commits as individual commits instead of >> squashing them.) > > There were no conflicts to resolve - other than ChangeLog, of course. If it > makes a difference I can cherry-pick them again and push a 3-commit series. Probably not worth it. > > >>> 2f3ef606b91298855e9ea13ae0e0316c23f06c9b >>> a038fa3e14a477d4d72a26c2e139fa47d2774be2 >>> 33b4777ca1b7b456af8201b98eda27d1b272cbab >> >> ( >> When referring to previous commits, I find it nicer to also include the >> commit's subject. The current lkml/git practice when referring to previous >> commits I believe is to put the subject in parens, though I can't find the >> reference right now. Like: >> >> 2f3ef606b912 (frame: add skip_tailcall_frames) >> a038fa3e14a4 (stack: check frame_unwind_caller_id) >> 33b4777ca1b7 (btrace, frame: fix crash in get_frame_type) >> ) > > Changed this to "git log --oneline"'s output: > > 33b4777 btrace, frame: fix crash in get_frame_type > a038fa3 stack: check frame_unwind_caller_id > 2f3ef60 frame: add skip_tailcall_frames Thanks. I found the reference I was thinking of: https://www.kernel.org/doc/Documentation/SubmittingPatches "If you want to refer to a specific commit, don't just refer to the SHA-1 ID of the commit. Please also include the oneline summary of the commit, to make it easier for reviewers to know what it is about. Example: Commit e21d2170f36602ae2708 ("video: remove unnecessary platform_set_drvdata()") removed the unnecessary platform_set_drvdata(), but left the variable "dev" unused, delete it. You should also be sure to use at least the first twelve characters of the SHA-1 ID. The kernel repository holds a *lot* of objects, making collisions with shorter IDs a real possibility. Bear in mind that, even if there is no collision with your six-character ID now, that condition may change five years from now." Thanks, Pedro Alves