Re: FFmpeg considering GIT

Hi

On Fri, May 04, 2007 at 11:17:05AM -0700, Carl Worth wrote:

On Fri, 4 May 2007 13:46:28 +0000 (UTC), Michael Niedermayer wrote:

quoted

well, my example above was exagerated, noone ever reindented the whole
ffmpeg or checked in a old version over HEAD. what did and does occasionally
happen is that people check in several things at once (like a 100k reindenton
mixed with various functional changes)

That sounds like an opportunity to educate your contributors a bit on
what good commits should look like. 

we have a nice svn policy which explains that, also people wont receive
write access without having submitted a few clean patches first
so i dont know if more education would really help, the problems are IMHO
rather caused by a mix of lazyness, arrogance and plain oversight
but please dont missunderstand, these problems are not that common, its
rather once every few month

So I think this is more a social
issue than a technical issue, 

yes i think so too, the added push after commit wont stop a bad commit
as the developer already saw the change when running svn diff ...

(but git has some technical means that
make it much easier to address the social issues).

Your description above makes an assumption that there is a single
central repository that multiple people push changes into, (which is
really the only way to organize a project with svn or cvs). And with
those systems all you get is a bit than you can flip on for whether
you trust someone to push changes into the repository or not. But git
is much more flexible than that.

The opposite extreme is to organize the project in a way similar to
the linux kernel---all contributors maintain their own repositories
and things get merged only when a maintainer reviews and pulls. With
this approach, garbage never lands in your own repository by
definition, (since you don't pull if it looks like garbage to you). So
that solves the problem, but this organization might seem too radical
a shift for your project.

yes, id like to switch ffmpeg to git or mercurial as that seems like a
good idea and many of our developers seem to want it, the question
about the organization is a different thing, not a single ffmpeg 
developer suggested to change the current "every developer has write access"
system, actually its even more than just that, almost every mplayer
developer has technically write access to ffmpeg and almost every ffmpeg
developer has technically write access to mplayer and this has never
caused a problem ...

also its kinda nice to review a patch and reply with "looks ok" and
someone else applies the patch locally, tests it extensively and
commits it, it reduces the work for reviewers ...


[...]

quoted

well if git blame and others could somehow be told to automatically ignore
nonsense changes and matching nonsense reverts that would be great
maybe by searching for some keyword in the revert message?

That sounds like a bad technical workaround for a problem that really
shouldn't exist. You should look for ways to create the history you'd
really like to have rather than trying to find a way to get the tool
to ignore the history that's actually there.

Sure, mistakes will happen. Just learn to live with that.

btw, that leads me to another minor issue, i think commit log
messages cannot be changed in git after they are public, while we
commonly did change them to improve them, the issue simply is that some
developers are not good at writing nice commit log messages, sometimes
due them being plain bad in english or bad at writing descriptive
log messages ...

also our docs team loves to correct spelling errors in the commit messages
not that i consider that of any importance :)

Oh, and I also think the emphasis on "blame" is due to a lack of other
more powerful history exploration features in other systems. For

yes

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope