[FFmpeg-cvslog] r14363 - in trunk/libavcodec: ra288.c ra288.h

[Michael Niedermayer]

On Fri, Jul 25, 2008 at 12:50:33AM +0300, Uoti Urpala wrote:
> On Thu, 2008-07-24 at 22:39 +0200, Michael Niedermayer wrote:
> > On Thu, Jul 24, 2008 at 08:16:31PM +0300, Uoti Urpala wrote:
> > > On Thu, 2008-07-24 at 18:24 +0200, Michael Niedermayer wrote:
> > > > and reading svnlog with a (non modified) MUA will also show the filename
> > [...]
> > > context information in the message is important again - even if you'd
> > > also add the filename list in the subject both the log message and
> > > filename list would not be visible for many commits unless you'd
> > > configure your MUA to use a lot of screen space per subject line.
> > > 
> > > So instead of of
> > > [FFmpeg-cvslog] r14265 - trunk/libavutil/intreadwrite.h
> > > [FFmpeg-cvslog] r14275 - trunk/libavutil/intreadwrite.h
> > > you'd have
> > > [FFmpeg-cvslog] r14265 - Rearrange AV_[RW][BL]*() macros
> > > [FFmpeg-cvslog] r14275 - intreadwrite: support DEC compiler __unaligned type qualifier
> 
> > I suggest:
> > 14265 u/intreadwrite.h - Rearrange AV_[RW][BL]*() macros
> > 14275 u/intreadwrite.h - support DEC compiler __unaligned type qualifier
> > 
> > Mine needs 14 chars less
> 
> It's misleading to mix dropping the list prefix with other changes in
> one length comparison. Whether to use the prefix is an independent
> issue.

Its not independent, if we want commit messages and filenames in the subj,
it makes sense to drop the prefix, it might not make sense otherwise.


> 
> >  and displays both the filename and the commit msg
> > and if the space for the filename is not enough for a list of names a + can
> > be added at the end to indicate there are more.
> 
> What would "the space for the filename"[s] be? There is no amount of
> space you could safely use for them at the start of the subject without
> increasing the likelihood that (more from) the end of the log message is
> hidden. 

What is it that you are trying to say? 
That a commit message could have any arbitrary finite length and thus
n-1 could always be too small while n would be enough? And that because
of that the commit message must always be shown alone?
come on, with that reasoning we may not display anything else on the whole
screen than a single commit message.


> 
> > but 2 filenames should easily have space in there, and with more the commit
> > message should probably clarify what part is being changed anyway.
> 
> 2 filenames can already use a significant portion of the space for
> commit-specific information (revision number and possible list prefix
> already take some space from the subject field). What do you even
> concretely propose? That the script show the first 2 filenames? No
> filenames at all if >= 3 files are changed? With no regard to the length
> of those names?

My suggestion would be a variable size field for the revission number,
a fixed size field (in chars) that is used for
filenames, we currently have a (totally useless) list prefix that noone
ever complained about that can easily be removed. The rest of the subject
can then be the first line of the commit message.
directories can easily be abbreviated to f/ c/ u/ for lavf/lavc/lavu
If the filename field is too short for all a + is placed at its end.
We might also use abbreviations like intreadwrite.c/h if that can be
implemented easily.

Above should be rather trivial to implement, and i think you will agree
that it is an improvment compared to the current pure filename list.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080725/de48ced2/attachment.pgp>