[FFmpeg-devel] [Ffmpeg-devel] SVN dump

[Trent Piepho]

On Tue, 1 May 2007, Uoti Urpala wrote:
> On Tue, 2007-05-01 at 21:57 +0200, Michael Niedermayer wrote:
> > as can be seen git properly merged the later change to "test" it didnt just
> > recommit it with a new date, also:
>
> If you use "git cherry-pick" that does create a new commit for the
> change. It just uses the same commit message and timestamp by default
> (equivalent to using the "-c" flag to commit, and you can change those
> if you want).

Using Mercurial's "hg export" and then "hg import" does the same thing.  It
creates a new commit that's otherwise the same as the old commit.

Mercurial does have an extension (it's part of the core, not some extra
thing you must install) that does cherry-picking "for real".  I'm not sure
exactly what it does, I think something like create a new change but also
make a link from it to the old change it's a copy of, so that hg knows the
two changes are really the same change.

> Now easy "rebuilds" to create a revised version of history are more
> useful with git because you can have private or semiprivate branches
> with history containing several commits, and then rebuild the history
> before committing it to a more public repository. However if you modify
> already existing history like that in a public repository it will break
> all existing checkouts (basically you're removing the existing branch
> and replacing it with a different one with the same name).

Same in Mercurial.  You can easily use 'hg strip' to remove history, fix
it, and then put back only what you want.  But if someone else has pulled
that history, they will have to re-clone to get their copy of the history
revised.