Hi, On Thu, May 03, 2007 at 08:00:16PM CEST, Uwe Kleine-König wrote: > 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 "Pasky" Baudis Stuff: http://pasky.or.cz/ Ever try. Ever fail. No matter. // Try again. Fail again. Fail better. -- Samuel Beckett - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html