[FFmpeg-cvslog] r13444 - in trunk: libavcodec/acelp_vectors.h libavcodec/cook.c libavcodec/dnxhdenc.c libavcodec/h264.c libavcodec/qdm2.c libavcodec/qtrle.c libavcodec/vc1.c libavcodec/vp3.c libavcodec/vqavideo.c libavfilter/avfilter.h libavformat/avidec.c libavformat/ipmovie.c libavformat/nsvdec.c libavformat/rl2.c libavformat/rmenc.c

Måns Rullgård mans
Wed May 28 16:25:23 CEST 2008


Diego Biurrun <diego at biurrun.de> writes:

> On Tue, May 27, 2008 at 05:30:02PM +0200, Michael Niedermayer wrote:
>> On Tue, May 27, 2008 at 03:06:35PM +0200, Diego Biurrun wrote:
>> > On Tue, May 27, 2008 at 03:00:49PM +0200, Benoit Fouet wrote:
>> > > Diego Biurrun wrote:
>> > > > On Tue, May 27, 2008 at 01:39:48PM +0100, M?ns Rullg?rd wrote:
>> > > >   
>> > > >> Diego Biurrun <diego at biurrun.de> writes:
>> > > >>     
>> > > >>> but within FFmpeg indexes is much more widespread.
>> > > >>>       
>> > > >> Does it matter if both are used?  Pointless changes like this make svn
>> > > >> blame less useful.
>> > > >
>> > > > Depends what you care about.  I do somewhat care about spelling
>> > > > consistency, but of course this is not particularly high priority.  But
>> > > > I also do not mind stepping through a few iterations in svn blame...
>> > > 
>> > > and do you care about people feeling the other way ?
>> > 
>> > That's kind of a loaded question.  
>> 
>> > Prior to other people voicing their
>> > opinions, I cannot read their minds.
>> 
>> Iam glad to hear that you can do afterwards ;)
>> 
>> and
>> Prior to the commit other people could not read your mind, thus "could not"
>> voice their oppinion.
>
> It just did not occur to me prior to committing. Anyway, the issue is
> very minor IMO, yet I sense a big bikeshed nearby...

I've lost count of the number of times a simple blame lookup has taken
significant time because of useless fixes like this being committed,
most of them by you.  Some were things like whitespace cleanup, which
I agree should be done.  Pure renaming missions, like this one, I
think are doing more harm than good, however.  If you feel strongly
about consistency, make sure new patches are good, but please leave
existing code alone.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-cvslog mailing list