[MPlayer-dev-eng] [PATCH] add VDPAU IMGFMTs
Uoti Urpala
uoti.urpala at pp1.inet.fi
Fri Feb 13 17:23:26 CET 2009
On Fri, 2009-02-13 at 09:47 +0100, Reimar Döffinger wrote:
> On Fri, Feb 13, 2009 at 06:18:45AM +0200, Uoti Urpala wrote:
> > I suggest you consider doing such changes which won't be relevant for
> > the release on top of my git branch instead of svn.
>
> My goal is to get it into SVN, and currently I consider git a
> not-so-good choice for the _central_ repository.
> git-svn to me seems to work well enough to provide developers with the
> ability to use git to me, without scaring anyone away who prefers to use
> SVN with its more advanced GUI support.
git-svn still lacks significant functionality compared to git. It does
not support merges. It loses authorship information and breaks history
when doing the commit to SVN. It would have been inferior for the
changes I've done. And anyway the most important practical argument is
that now the best development repository _already is_ in git, and
porting it to SVN would be hard.
> > If someone wants to
> > flame at least explain how you'd maintain a better version - and current
> > svn isn't one.
>
> SVN is a reviewed version, that is the only argument and unfortunately
> that is enough for me.
That's rather vague, and I'm not sure exactly what concern you consider
important. SVN contains more badly designed and implemented code.
If you don't want to use git then what do you intend to do? Do you plan
to do all the work required to turn SVN into something competitive (and
think you'd actually succeed)? Or will you insist on working on SVN even
if that will only cause unnecessary porting work or mean your changes
will be wasted?
> > I don't see any major problem with doing it in such parts, but I don't
> > understand your rationale for it either. Why do you need to commit
> > nonfunctional parts if you're maintaining things as a git branch anyway?
> > I mean what benefit does it give to have this in svn instead of your git
> > branch?
>
> Changes to SVN are reviewed, changes to git not, and I will commit crap
> to the git repository which would be plain unacceptable in SVN
> (that is what it exists for).
Nothing about such a workflow requires the cleaned-up version to
immediately go to the main development branch though. And testing later
with a more complete system could turn up new problems which sometimes
are most nicely fixed by modifying the earlier commits before they are
part of the common history.
> Moving things as soon as I consider them non-crappy means I don't have
> to bother with it / filter it out when I do a "git diff" and others
> don't have to review later as part of a giant patch.
I'm not sure what exactly your "git diff" issue is, but I doubt it's
anything that would not have an easier fix. And I don't see how the
patch would be any bigger later. Your review argument sounds like its
result would basically boil down to "it's better to spread related
changes over a long period of time", and I don't agree with that.
More information about the MPlayer-dev-eng
mailing list