Hi,
On Thu, May 03, 2007 at 08:00:16PM CEST, Uwe Kleine-König wrote:
Show 30 quoted lines
> Panagiotis Issaris wrote:
> > 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
I believe that the development scheme is largely independent on the
version control system, except that git makes the "both ways" equally
easy. But that doesn't mean that the "multiple people with commit
access" scheme is wrong or anything. It has important upsides as well -
there's no single human point of failure (_yes_, if the maintainer gets
stuck in hospital for two months you can fork and maintain own
repository, but then it's again just you and it is complicated socially
etc.), the load of the maintainer is significantly lowered, and in many
projects there is simply no "single maintainer" but a team of people
where decisions are made by consensus.
Still, if this kind of bogus change checkins happens at any frequent
rate in the ffmpeg project, there is a serious problem somewhere. :-)
But I think the git way of alleviating this problem would be to have a
way to hint the pickaxe and blame tools to ignore changes in given
commits. So, you don't _cover up_ the messy things that happened during
the history, but avoid in getting in the way in your view. You can still
look it up (with git log or something) in case you'd need to (perhaps
the revert patch was a bit complicated because of conflicting with some
other changes, and a subtle bug was introduced; this would be thousand
times harder to track down if you would've rewritten the history).
Would crafting up a patch to implement something like this help ffmpeg
people in their decision?
Let's say you have .git/info/reverts with one "revert pair" (two
commit ids, one for the bogus change and one for reverting it) per line,
and the blame/pickaxe tools take it into account. The downside is that
this isn't preserved over clones and fetches. That's a pretty big one.
Another way might be to have say a magic "Reverts: commitid" line at
the last paragraph of a commit message recognized by git. The downside
is that the body of commit message might have magic meaning for some
non-core plumbing; I'm not sure how big a downside that is. For adding
it to commit header it might be a little bit too non-core, I might meet
with Linus' ethernal fury, and I'm not sure how big of a compatibility
problem would it be.
Ideas?
Petr Baudis <pasky@suse.cz>