[FFmpeg-cvslog] r14267 - trunk/libavcodec/ra288.c

[Vitor Sessak]

M?ns Rullg?rd wrote:
> Vitor Sessak <vitor1001 at gmail.com> writes:
> 
>> M?ns Rullg?rd wrote:
>>> Vitor Sessak <vitor1001 at gmail.com> writes:
>>>
>>>> Diego Biurrun wrote:
>>>>> On Fri, Jul 18, 2008 at 12:42:23AM +0200, vitor wrote:
>>>>>> Log:
>>>>>> Simplify
>>>>> Can we *please* have more descriptive commit messages?  How long can it
>>>>> take you to explain *what* you simplified?
>>>> For such obvious cleanups I'm against spending more time thinking about 
>>>> the commit message than doing the code changes (even more so as what is 
>>>> "cleaner" is a matter of taste, so it is non trivial to explain why the 
>>>> new code is better in a commit msg). But if you could suggest anything 
>>>> better that I could copy-paste for those kind of clean-up commits, I'd 
>>>> happily do so.
>>> A simple "ra288:" prefix would suffice in this case.
>> Then we go back to the flamewar about if the commit messages should be 
>> understandable with or without seeing the list of changed files. From 
>> what I followed of the discussion, this is a problem almost only for 
>> git.
> 
> Here's some sample output from "svn log":
> 
> ------------------------------------------------------------------------
> r14274 | mru | 2008-07-18 02:07:17 +0100 (Fri, 18 Jul 2008) | 4 lines
> 
> MPEGTS: Improve probe function
> 
> When a sync byte is found, check that transport_error_indicator is zero,
> and adaptation_field_control is valid (non-zero).
> ------------------------------------------------------------------------
> r14273 | bcoudurier | 2008-07-18 01:24:31 +0100 (Fri, 18 Jul 2008) | 1 line
> 
> cosmetics, remove space
> ------------------------------------------------------------------------
> r14272 | bcoudurier | 2008-07-18 01:23:37 +0100 (Fri, 18 Jul 2008) | 1 line
> 
> return max score when ftyp atom is encoutered
> ------------------------------------------------------------------------
> r14268 | vitor | 2008-07-17 23:59:53 +0100 (Thu, 17 Jul 2008) | 1 line
> 
> Simplify
> ------------------------------------------------------------------------
> r14263 | diego | 2008-07-17 17:28:48 +0100 (Thu, 17 Jul 2008) | 3 lines
> 
> Replace LDLATEFLAGS hackery by proper LDFLAGS tests.
> The original reasons for LDLATEFLAGS are lost in the mists of time.
> 
> ------------------------------------------------------------------------

That's explains why nobody uses "svn log" in the tree root.

> Looking at this, how would you know what was simplified in r14268?
> Contrast this with the information given for r14274.
> 
>> Does git have any module support (and in the case of ffmpeg, each 
> 
> When I said module, I didn't mean it in any sense that anything would
> need support for, and certainly not in the cvs sense.

It looks like more or less what you are trying to do by hand in the svn 
logs...

>> codec would be a separate module) so that in the history it is marked 
>> that the "simplify" commit changed only the ra288 module? Adding 
>> "ra288:" in the log is a bit of metadata duplication...
> 
> No, it's common sense. 

So common you could not get a consensus about it in -devel

> Now stop arguing, 

yes, I've lost enough time. I recommend you do the same.

> and do as I tell you.

no

> Some day, you'll realise I was right.

Now that's a good technical argument. What's next? "But that's how they 
do it in the linux kernel!"?

-Vitor

PS for the others members of the list: not that I care that much about 
putting "module:" in the svn logs or not. It's just that while there is 
no agreed upon policy about it, I'll keep doing as I think it is best.