Re: FFmpeg considering GIT

From: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Date: May 3, 2007, 18:00 UTC
Message-ID: <20070503180016.GB21333@informatik.uni-freiburg.de>
In-Reply-To: <loom.20070502T111026-882@post.gmane.org>

Hello,

Panagiotis Issaris wrote:

Show 7 quoted lines

> There are some other things the FFmpeg maintainer mentions, namely:
> * He wants to be able to revert a commit in some way without "wiping" history.
> That is without committing a patch which reverses the broken commit, as this
> would pollute "git blame". The maintainer sees this as critical feature for
> switching to git as it apparently can be doing using Subversion:
> "in svn we can do this with svn cp from a specific
> revission git and mercurial lack proper copy support"

To add more context, Michael Niedermayer (=FFmpeg maintainer) wrote (in [1]):

	let me explain a little bit why this is critically needed
	think of someone misstakely commiting the whole ffmpeg
	reindented or mistakely commiting a old ffmpeg version over the
	new or another total messup, these things do happen, and
	especially if they cannot be corrected and at the time where
	none of the developers is around

For me this sounds like: I don't want people with commit access doing this, and if they do, I want to be able to revert it.

If FFmpeg used a development scheme similar to the linux kernel, there should be no need for revert: The upstream maintainer only needs to pay attention to the things he does directly (he probably does in any case) and check the patches he applies and the trees he pulls. As git gives a diffstat on pull and he reviews patches before applying the problem is maybe gone?

Commit access is simply different in a distributed environment, see http://thread.gmane.org/gmane.comp.version-control.git/45849/focus=45956

Best regards Uwe

> [1]
> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/49673

-- 
Uwe Kleine-König

http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2