[MPlayer-cvslog] r25301 - trunk/vidix/radeon_vid.c

Diego Biurrun diego at biurrun.de
Fri Dec 7 00:45:00 CET 2007


On Thu, Dec 06, 2007 at 07:54:54PM +0100, Michael Niedermayer wrote:
> On Thu, Dec 06, 2007 at 08:03:07AM +0100, Diego Biurrun wrote:
> > On Wed, Dec 05, 2007 at 04:22:47PM +0100, Reimar Döffinger wrote:
> > > On Wed, Dec 05, 2007 at 04:54:01PM +0200, Ivan Kalvachev wrote:
> > > > 2007/12/5, Diego Biurrun <diego at biurrun.de>:
> > > > > On Tue, Dec 04, 2007 at 11:22:24PM +0100, ben wrote:
> > > > > >
> > > > > > Log:
> > > > > > sync with vidix.sf.net r320: ati radeon >= R5xx do no more have overlay engine but use 3D texture mapping instead, hence no chance to be supported by this driver
> > > > >
> > > > > Please keep lines below 80 characters, thank you.
> > > > 
> > > > Would you explain why is this required?
> > > 
> > > Required seems a bit strong to me, but I see several reasons:
> > > More than that and it
> > > 1) becomes ugly when quoting in an email
> > > 2) the line breaks are more or less at "random" points which can easily
> > >    harder to read than doing the break at an appropriate place
> > > 3) Lines longer than 80 lines very fast become really hard to read, at
> > >    least for me (actually the limit is more around 65 lines, but 80
> > >    is bearable), which also means a larger terminal is not a solution to
> > >    point 2.
> > 
> > Furthermore, not all programs that handle commit messages insert line
> > breaks at all!  ViewVC does not for example, which makes overly long
> > lines in commit messages particularly annoying.
> 
> ehm, ViewVC cannot insert line breaks because it doesnt know your
> screen/window/terminal size
> 
> the bug in ViewVC is that it uses <pre> tags which is just WRONG
> it shouls just use p and insert <br/> where ones were in the original msgs
> 
> also the fact that besides svn clients which break lines there exist buggy
> ones which do not is hardly an argument for the way svn log messages should be
> written.

No, I don't want the client to break lines arbitrarily, it makes things
like compiler output quoted in a commit message hard to read.

> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Let us carefully observe those good qualities wherein our enemies excel us
> and endeavor to excel them, by avoiding what is faulty, and imitating what
> is excellent in them. -- Plutarch

Writing good commit messages comes to mind.

Diego



More information about the MPlayer-cvslog mailing list