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

[Uoti Urpala]

On Tue, 2007-05-01 at 23:34 +0200, Michael Niedermayer wrote:
> > You can't
> > remove a "bad" part of history in an existing branch. This is similar to
> > rebuilding a repository in svn.
> > 
> > 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).
> 
> hmm so git uses the branch name and will fatally fail if it gets renamed?
> also note i did NOT remove any branch i just renamed them

git does use the branch name to remember what is the "upstream" branch
that commands like "git pull" by default get new changes from. However
the problem here is not so much about the renames, but rather that the
HEAD of the new branch with the same name (whether created with renames
or with commands like "git reset --hard XXXX") is not a descendant of
the old branch HEAD. When you replace the branch like that (not just
adding new commits as children of the existing HEAD, but replacing the
history with a different one which is not a superset of the old)
updating existing checkouts to the new branch state requires manual
intervention, and can cause problems for people who had additional
commits in their repositories.

Basically the only operation you can do in a public repository without
causing problems is committing new versions. If you try to remove
existing commits or otherwise alter already established history that
basically means saying "we'll abandon the current repository, let's
start a new one", and everyone needs to manually change to the new
repository. git does have several tools such as rebase for modifying
history; however those are mainly for private repositories and uses such
as integrating changes from one branch to another. "The official FFmpeg
git repository" should never have changes other than normal commits and
merges except in very special circumstances. If you have a separate
branch for developing a new feature then that could have its history
modified, erroneous commits removed etc before it's merged into the main
FFmpeg repository.

> now lets assume i dont rename master<->new_branch, then this should work
> fine, using new_branch instead of master?
> i cant see how this could fail, i just create a new branch (like a branch
> for a release) i port a few good changes from one branch to the other and
> then just continue development with the new branch ...

Well it works (or doesn't) in the same sense that it works WITH the
rename. The new branch is a completely valid branch of its own, and you
can do whatever you want with it. There's no problem if it was a private
branch. However if the old branch was public then people will get
problems and will be annoyed when you abandon it and start a new one
instead (they could also have not-(yet-)-merged changes on top of the
old branch etc...).