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