Re: FFmpeg considering GIT

From: Jakub Narebski <jnareb@gmail.com>
Date: May 2, 2007, 23:48 UTC
Message-ID: <f1b806$nc7$1@sea.gmane.org>
In-Reply-To: <loom.20070502T111026-882@post.gmane.org>

Panagiotis Issaris wrote:

Show 21 quoted lines

> Some of the people of the FFmpeg project are looking at both GIT and Mercurial
> as possible replacements for the current Subversion repository. They have some
> questions regarding the possibility of doing certain things, which I prefer not
> to answer as I am not sure my answer would be correct :) Which is why I am
> posting here...
> 
> The questions are stated in this e-mail [1]. One of the things that are being
> discussed is the following action on a publicly mirrored repository:
> git branch -m master dead_end
> git branch -m last_good master
> 
> I'd think this would fail as people could have pulled from the repository while
> the "dead_end" commit was already available, right?
> 
> 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"

About removing a commit: assume that you have the following history

  A---B---C---D---E          <---  branch

Now you have noticed that commit C is wrong, and it should not be there. One solution, which is used usually if the history was published, is to revert a commit, resulting in the following history:

  A---B---C---D---E---C^-1   <--- branch

(which is what git-revert does).

Now if you didn't publish this history, or you don't care that you are rewriting history, it is fairly easy to remove commit C (for example using "git rebase --onto B D E" command), resulting in the following history:

  A---B---C---D---E
       \
        \
         \----D'--E'          <--- branch

(which after pruning would result in A---B---D'--E' history).

The problem exists _only_ if somebody based his/her work on commit C or its descendant, i.e. original D, E commits. He/she would have to rebase his/her work on top of _changed_ (moved) commits D' and E'.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git