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

[Uoti Urpala]

On Fri, 2008-07-18 at 15:13 +0200, Vitor Sessak wrote:
> Uoti Urpala wrote:
> > FFmpeg happens to have many "easy case" commits which change a single
> > file with clearly limited functionality (specific to one codec/format).
> 
> Yes, and that is important. In FFmpeg, 99% of the commits either
> 
> 1. Change only codecname.{c,h} (you'd put "codecname:" in the logs)
> 2. Change only Makefile/configure (you'd put "build:" in the logs)
> 3. You wouldn't add "module:" in the logs because it is not specific to 
> any module (like fixing bugs in util.c)
> 4. Adding "module:" is redundant with the commit message (ex: "ARM: 
> ARMv6 optimised bswap_16/32")

Not close to 99%. And even for those cases there is no automatic
solution that would actually work well now.

> > But it's not the only case so you should consider how the system works
> > in less trivial cases.
> 
> Why? Why do it always by hand when you need to do it only in the 1% 
> corner cases? I'm favorable to adding "ra288:" to the log of a change in 
> libavcodec/utils.c relevant only to ra288.

What you seem to be missing is that a human must check and approve the
result. If you just write a commit message like "simplify" then it is
not possible for the computer to tell whether 1) you consider
automatically filling in the default context information guessed from
the changed file "libavcodec/ra288.c" to be appropriate or 2) context
information is already present in a form the computer doesn't easily
recognize or is completely missing but cannot be easily guessed from the
file list. Cases where the computer can't fill in the most appropriate
context are more common than 1%.

If you want to create a script to start your editor with "ra288:"
already filled in when you start writing a commit message feel free to
do so. But trying to automatically fill it in later with no human check
of the result doesn't work well.