From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7144 invoked by alias); 21 Apr 2014 16:06:55 -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 7134 invoked by uid 89); 21 Apr 2014 16:06:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 21 Apr 2014 16:06:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 715B51160ED; Mon, 21 Apr 2014 12:06:52 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Qy4q-4QO34dv; Mon, 21 Apr 2014 12:06:52 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4A2341160CB; Mon, 21 Apr 2014 12:06:52 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A023FE09B7; Mon, 21 Apr 2014 09:06:51 -0700 (PDT) Date: Mon, 21 Apr 2014 16:06:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: git cherry-pick -x Message-ID: <20140421160651.GD4477@adacore.com> References: <83ioq4fmkg.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ioq4fmkg.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-04/txt/msg00408.txt.bz2 > What are the views here on using the -x switch to git cherry-pick, > when cherry-picking commits from master to a release branch? Is that > deemed useful? If so, should we always use it? My personal view on this is that I have never found the extra message to be all that useful to have, but I don't mind them. Watch out for one little nit: If the revision log is a single-line log, then the extra info is added right after it, breaking the convention that the second line of revision logs should always be empty. -- Joel