From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 15 Sep 2010 14:23:18 +1000

On 15 September 2010 13:57, Paul Louden <paulthenerd_at_gmail.com> wrote:
>  On 9/14/2010 10:22 PM, Karl Kurbjun wrote:
>>
>> Anyone that knows the language syntax can quickly determine the purpose of
>> the commit by looking at the diff if it was not clear to them.
>>
> The point of the commit log is so that someone can skim descriptions rather
> than having to read through the diff of commits.
>
> The reason for this post was less to single out something specific, but
> rather to ask the question "should we ask that commit descriptions have a
> minimum level of descriptiveness?" For that reason, it's pretty essential
> that it be publicly discussed.
>
> I also don't think anyone was particularly impolite, so I don't see your
> reason for the focus on that word.
>

If anything that argument is one *for* the short "fix red", "bugger"
commit messages NOT AGAINST THEM.
When skimming the commit logs you know immediately to go straight past
any of those messages.

Besides, if you are searching for possible breaks and using the commit
message as your first filter is incredibly dangerous. You are having a
whinge about an inconsequential commit which is IMPOSSIBLE to create
bugs yet 4 before it
(http://svn.rockbox.org/viewvc.cgi?view=rev;revision=28073) doesn't
get a mention at all? After all, that commit probably does cause minor
(maybe major...) issues and in all honesty should have got at least 3x
as much text in the commit message. In fact it shouldn't have been
done like that at all (git merge --squash branch) and should have been
committed as the 30odd git commits I did locally.

Like I said, searching for breaks using the commit message is just
plain wrong. My method (admitadly because I think I have a pretty good
understanding of how things fit in the code) is first by the filename,
then who commited it, then depends on the other files in that commit I
would look at the commit message or the actual diff.
Received on 2010-09-15