[FFmpeg-cvslog] r17068 - in trunk/libavformat: audiointerleave.c audiointerleave.h

[Baptiste Coudurier]

Reimar D?ffinger wrote:
> On Sun, Feb 08, 2009 at 03:09:34PM -0800, Baptiste Coudurier wrote:
>> Besides, Im sorry but I still think the commit message cannot be
>> separated from the diff, and I won't change my mind.
> 
> Well, it already is separated, svn log will only show the message and
> the message is above and the patch below.
> Also by your argument you could just always give an empty commit
> message.

The mail everybody get from -cvslog is not separated, everybody needing
more information will search for the diff, and comment on -cvslog ml if
wanted, therefore reading the whole mail.
Repeating this information in the commit message only adds redundant
information. That's what getting the diff in -cvslog ml is for, and is
very useful.

Besides, writing more in the commit message than more lines in the code
looks very awkward.

Commit message should contain sufficient information to understand the
"meaning" of the commit, not detail every character writing in the code,
anyway you can ask the dev if it is not clear.

>> Now if you want to change the commit message, feel free to do so, but I
>> consider commit messages, on which you commented, fine.
> 
> I can't understand how you can consider it fine to force every single
> reader of this list to read the whole 20 lines or so of the diff just to
> find out if it concerns them or not, instead of allowing them to read
> the subject (for seeing affected files) and a single line (for knowing
> which part of the file).

if you are talking about the "list", then you get the full mail, so this
your comment is irrelevant, you get all the information.

Besides, your concern is only about files you care about, and you get it
in the commit mail. A commit is comprised of a message, a diff, files it
modifies, removes or adds.

Now if your tools do not mention this information, IMHO tools need to be
enhanced. I personally can only barely work without the -cvslog ml, and
I guess others cannot really either.

I won't continue this useless discussion.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org