[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8465 - trunk/libavformat/utils.c

Uoti Urpala uoti.urpala
Wed Mar 21 18:47:37 CET 2007

On Wed, 2007-03-21 at 17:57 +0100, Reimar D?ffinger wrote:
> On Wed, Mar 21, 2007 at 05:46:35PM +0200, Uoti Urpala wrote:
> > I also think length isn't that important even if it takes
> > more than two lines.
> Just to explain why length of log messages seems important at all to me:
> 1) svn log output is just horrible to read, long log messages make it
> even worse, esp. as it defaults to giving all info and there is no
> simple way to make it say print the 10 messages before and after the given
> revision for that specified line. If someone knows some magic to make
> svn log more useful I'm interested...

You were using git already weren't you? If you want sophisticated log
options I'd recommend doing that with git log.

> 2) grep has a much higher probability of false positives if there is
> much more text, esp. since grep makes it a bit hard to "refine" searches
> (though it is of course possible).

More text can increase the probability of correct matches too. I don't
see why this would favor shorter messages.

> > 8461:
> > =====
> > treat frame_size > 1 as compressed audio
> > =====
> > 
> > This requires at least checking which file(s) the commit changes to make
> > much sense, and still doesn't tell what kind of practical effect this
> > change might have. I think it would be better to mention "mov/mp4 muxer"
> > in the commit message itself and possibly mention which practical case
> > this improves/fixes.
> The problem here is that including the file name adds redundant
> information, which feels stupid to me, and also complicates the logs

I don't consider it redundant. I think it should be possible to skim the
logs in a compact format like "git log --pretty=oneline". Always
including the paths automatically takes significantly more space than
including the necessary context would take in most messages.

If you always try to leave information out of the log messages when it
can be implied from the paths then some messages still won't require it,
meaning that when you try to skim through a list of logs you either have
to always read the paths first (often redundant) or you have to first
try reading the messages and then go to the path list when the message
doesn't make sense otherwise (clumsier and slower than having the
information in the message would be).

> when reading only the log for a single file. It also is not as good as
> an automated solution, since at least I end up writing the file name
> sometimes with path, without path, with extension or without or not
> writing the filename at all but something like "mov/mp4 muxer" which is
> suboptimal for a grep search.

You wouldn't normally need to write the full paths/names of all affected
files for the message to make sense alone. If I thought it was necessary
to have the full path information when reading any commit message then I
would not argue for making the messages self-contained. It is precisely
because full path information is often NOT required for understanding
the summary of the commit that I don't want to always have it there
(which can't be avoided if some messages do not make sense unless you
automatically add the path information to all of them).

If you want to make a search based on files changed then there are
better ways to do that than grepping the log.

> IMO this is really a huge shortcoming of svn log (not including the
> affected file names) and should be "fixed" there somehow.

You can list changed paths with "svn log -v". As explained above my
reason for wanting the message to make sense without a path list is not
that it would be hard to get the list.

More information about the ffmpeg-devel mailing list