Re: small request regarding commits in binutils-gdb.git

[Fred Cooke <fred dot cooke at gmail dot com>]

I'd be with you, Mike, but these packages are regularly distributed
without source control, as tarballs, and as such it's useful. For my
own stuff it's not possible to build without git present, it's a
prerequisite.

The first line of a git commit should say enough about the why/what to
stand alone. The rest should add detail. If the first line can not
achieve this, it makes log view forms with only the first line pretty
much useless. Line length restrictions are archaic IMO, however the
standard tooling makes long lines look bad on purpose, so...

In any case, I totally agree that pasting a "what changed" entry is
not OK, and adding the full "I did it because" email content is a VERY
good thing.

eg

> Removed duplicated code in bad style from XY arch.
>
> This code was added for ABC reason, however it duplicates LMNOP code and is in bad taste. Removing it lightens the maintenance burden, while retaining the functionality in the other superior form.

What: Code was removed from XY arch
Why: Because it was poor style and duplicated
Detail: More human friendly verbose version of the same

On Wed, Jan 15, 2014 at 6:12 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Wednesday 15 January 2014 11:57:45 Eli Zaretskii wrote:
>> > Date: Wed, 15 Jan 2014 20:25:18 +0400
>> > From: Joel Brobecker <brobecker@adacore.com>
>> > Cc: binutils@sourceware.org, gdb-patches@sourceware.org
>> >
>> > But even with this example, it isn't just a repeat.
>>
>> I didn't say it was just a repeat, I said most of it just repeats.
>>
>> > The text before the ChangeLog says what the intent of the patch is,
>> > and provides extra information that usually doesn't go into the
>> > ChangeLog entry. For example, it says "This makes it usable in more
>> > places".
>>
>> Why not have this as part of the log entry.  Here's an example (from
>> Emacs):
>
> i'd lobby for just stopping the ChangeLog practice altogether :)
> -mike