From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63400 invoked by alias); 18 Nov 2019 17:55:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 63349 invoked by uid 89); 18 Nov 2019 17:55:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=cvs, e.t.c, emails X-HELO: mail-qt1-f196.google.com Received: from mail-qt1-f196.google.com (HELO mail-qt1-f196.google.com) (209.85.160.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Nov 2019 17:55:27 +0000 Received: by mail-qt1-f196.google.com with SMTP id g50so21207498qtb.4 for ; Mon, 18 Nov 2019 09:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=qKbAjRgVtF429ob1nIUX15SAfkotdDPnH1UBlOBBZ1s=; b=UD5MchX1gAPZUgxvfo8tHXeCH74uJoVDiUtAEmtB+BgCoW81wQIlSpiMq3WLwu23Ib CbeqB5WhpW/SSKhxXsSPuXNRaqo7NpC9BGkomHx+AAP+MSUTKKuJDqYWvHv2QxpGrk6t kmiARRRLTtYcTSdEsFENtf2yFaozE/HTAHczjrXWxsI0Nfn1T7m9bQYPXUy8/lk6x5F7 GZrmY8SVRDu6bOwT9D/fFKY5KWsPD0F2dT0VdMmlbMvZMj5HwQHnTEQHTOewavozKSaE kFeMinWrbekI2Jxg5uK0b/31L4neNA+K/Vft093cXZwqC4jOeu0reHnnmTCdTua4kzxm JPdw== Return-Path: Received: from [192.168.1.103] (173-230-163-230.cable.teksavvy.com. [173.230.163.230]) by smtp.gmail.com with ESMTPSA id f2sm8484599qkm.130.2019.11.18.09.55.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Nov 2019 09:55:23 -0800 (PST) Subject: Re: Commit messages and the move to git To: "Richard Earnshaw (lists)" , Segher Boessenkool Cc: esr@thyrus.com, law@redhat.com, gcc@gcc.gnu.org References: <20191107142727.GA72444@thyrsus.com> <20191109060151.GA82270@thyrsus.com> <78a57894-74f2-94d5-65a1-3ce2bd934f32@arm.com> <20191118155549.GH16031@gate.crashing.org> <20191118171115.GI16031@gate.crashing.org> <8c32c288-e9e6-b01b-7911-3f186116da85@gmail.com> <7c86495c-dcf9-e4a4-8d7a-4f1112dbc699@gmail.com> <73b65011-60f3-dd9e-b3b4-296090f27ddc@gmail.com> From: Nicholas Krause Message-ID: <9113691d-5a64-5afe-a2ec-f10e9626a2bc@gmail.com> Date: Mon, 18 Nov 2019 17:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00128.txt.bz2 On 11/18/19 12:46 PM, Richard Earnshaw (lists) wrote: > On 18/11/2019 17:25, Nicholas Krause wrote: >> >> On 11/18/19 12:23 PM, Nicholas Krause wrote: >>> >>> On 11/18/19 12:20 PM, Nicholas Krause wrote: >>>> >>>> On 11/18/19 12:11 PM, Segher Boessenkool wrote: >>>>> Hi Richard, >>>>> >>>>> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) >>>>> wrote: >>>>>> On 18/11/2019 15:55, Segher Boessenkool wrote: >>>>>>> That immediately shows some of the shortcomings of this >>>>>>> approach: the >>>>>>> subject line is much too long, but more importantly, it doesn't >>>>>>> make >>>>>>> much sense: it is not what the patch does, it is the description >>>>>>> of a >>>>>>> bug that is related in some way to this patch.  It is not >>>>>>> uncommon for >>>>>>> a commit to not fix the problem mentioned in the bug report (if >>>>>>> it *is* >>>>>>> a problem!), or not fix it completely. >>>>>>> >>>>>>> Then again, changing all such subject lines to read "patch" >>>>>>> could also >>>>>>> already be considered an improvement. >>>>>> Well the real question is whether such a summary is worse than the >>>>>> current situation of just printing the author in the wrong field.  I >>>>>> personally don't think it is. >>>>> I think that non-obviously-wrong-but-still-wrong info is not >>>>> something >>>>> we should introduce.  And, I think this will happen a *lot*. >>>>> >>>>> Maybe you can just put in artificial subjects like "Patch related to >>>>> PR12345" or the like?  That is correct, displays a lot better, and is >>>>> at least as useful (imo). >>>> >>>> I don't see but other projects  mention PRS or Bugzilla ids but >>>> >>>> more common in my experience is just mentioned the commit >>>> >>>> ids. For example this fixes commit id x introducing PR x. Commit >>>> >>>> ids are know good so having them linked in commit messages >>>> >>>> is much easier to track then PRs, I can just use git log -p commit id. >>>> >>>>> >>>>>> There are about 560 commits where the code highlights that the data >>>>>> might be suspect (usually a category mismatch). >>>>> What about commits that mention multiple PRs?  What do you do for >>>>> those? >>>>> (Are there as many of those as I think, anyway?)  With normally >>>>> very short >>>>> subjects you could put all of them in there :-) >>>> >>>> See my above but for this you would just state the main issue(s) in >>>> the commit >>>> >>>> message and in the body what commits/PRs are being handled. >>>> >>>> Not sure if that works for everyone but that's normally the best >>>> way in my >>>> >>>> experience, >>>> >>>> Nick >>>> >>>> Sorry but cced the others as this was a misclick. >> >> One of the emails CCed was boucing so I just fixed that as well. >> > > [strange, I'm not seeing bounces]. > >> Nick >> >>>> >>>>> >>>>> Segher > > SVN commit Ids can't be fixed here.  Not least because we don't know > the SHA code for the git commit at this point.  For legacy commit id's > we'll just need to keep the existing SVN repo available, so that folks > can look at it with, say, viewcvs. > > R. Richard, That's a problem but for legacy commits keeping the old cvs around would be good. Other projects had the problem of moving to git but not keeping that data around and causing issues.  The other thing I would point out in this discussion is to start figuring out history policies on branches e.t.c for merges, cherry picking and bisect. Merges are the obvious one but bisect and cherry picking will depend on the history choices over time as how useful they may become. I've yet to see history choices discussed whether it be straight linear, branches and merge e.t.c. but thought I will mention it again as I did at Cauldron briefly as this  will not be part of the merge but important for future planning git migration or project strategies and should be discussed or added to the wiki for git migration. Cheers, Nick