Re: FFmpeg considering GIT

Panagiotis Issaris wrote:

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