[FFmpeg-cvslog] r12972 - trunk/libavformat/mov.c

[Baptiste Coudurier]

Diego Biurrun wrote:
> On Fri, Apr 25, 2008 at 07:02:15PM +0200, Baptiste Coudurier wrote:
>> Diego Biurrun wrote:
>>> On Fri, Apr 25, 2008 at 06:52:31PM +0200, bcoudurier wrote:
>>>> Log:
>>>> yes it is true for mp4
>>> This commit message does not make sense on its own...
>> Well, I do think that the commit message cannot be separated from the
>> corresponding diff. Don't you think ?
> 
> No, that's precisely the point.  When you are looking at the output of
> 'svn log', the messages should make sense on its own without having to
> look at the diffs. If you have to look through all the diffs to make
> sense of commit messages, you might as well leave them out entirely.

I do not agree with that. You can be more explicit than what code does,
however code is the only reference, message can be wrong, and it has
already been in the past.
The best way to know what a commit does is to look at the diff.

Besides "svn diff -r x:y" is as easy as "svn log". I very rarely use
"svn log" and look at diffs instead.

> If you want to see an example of how not to do it, look at early MPlayer
> svn history.  When you have multiple commit messages that just say
> "10l", using version control is no longer very useful.

This is a bad argument IMHO, because people misbehaving does not make a
argument.
I clearly do not agree with you here, a version control is not useful
only for commit messages, it's way more useful for branching and history.

> Just adding something like "update comment:" to your commit message
> would do wonders.

And here I again don't agree with you, if I would adopt your idea,
adding only "update comment:" is clearly not sufficient because it does
not illustrate the removed comment.

The diff with the commit message are clearly explicit, repeating the
diff is useless and waste of bytes/network traffic ;)

> So to answer your question: Sometimes commit messages cannot be separated
> from the diffs, but they should be written in a way that this is
> possible.

Yes, "should", and this not to be mandatory.

> If they do not make sense on their own, they are bad and
> should be rewritten.

I think they must when the commit is unobvious, but not in every case.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG SAS                                     http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312