Re: FFmpeg considering GIT

From: Michael Niedermayer <michaelni@gmx.at>
Date: May 4, 2007, 20:24 UTC
Message-ID: <20070504202448.GD14859@MichaelsNB>
In-Reply-To: <87y7k4lahq.wl%cworth@cworth.org>

Hi

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

Show 8 quoted lines

> On Fri, 4 May 2007 13:46:28 +0000 (UTC), Michael Niedermayer wrote:
> > 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 ...

Show 17 quoted lines

> (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 ...

[...]

Show 11 quoted lines

> 
> > 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