Commit messages and the move to git

Nicholas Krause xerofoify@gmail.com
Mon Nov 18 17:24:00 GMT 2019


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.
>>
>> Segher



More information about the Gcc mailing list