Samuel Lucas Vaz de Mello <samuellucas@xxxxxxxxxxxxxx> writes: > I have a repository with code imported from CVS. > > I first imported from CVS using git 1.5.6 and we started to develop > in git branches. I run cvsimport periodically and merged the > changes from CVS (legacy developers) to our git branches. After > some time, I realized that the import was broken, upgraded to git > 1.6 and reimported the data. Now the imported data seems to be > correct and I finished with a history tree like this: > > (our branch1) X--Y--Z > merges> / \ > (our branch2) J--K--L--M--N--O--P > merges> / / / > (cvs old) ...A--B--C--D--E / > merges> / > (cvs new) ...A'-B'-C'-D'-E'-F' > > > There is any way to get rid of the (broken) cvs-old tree? > > I've tried to rebase, but the commits from A' and A are different, > it tries to reapply all history in CVS. > > I've tried to checkout a point before our changes start (B') and > then, using a script, cherry-pick all commits up to HEAD that are > not in cvs-old branch. This approach didn't handled well merges > between our branches (K-L-M and X-Y). > > The history from the beginning up to the point where our changes > started (...A--B) is quite large, so it would be nice for us to get > rid of it. > > Any suggestion on how to handle this? You can use grafts (see "Repository Layout" documentation) to prune 'cvs old' branches, by adding for each merge commit <c_i> with one side leading to 'cvs old' branch line to .git/info/grafts <c_i> <c_i^1> where <c_i> is full hexadecimal object name. Then check in gitk or some other history viewer if the history now looks like you wanted (looks sane). Then use "git filter-branch --all" to turn grafts into reality, check out correctness, then remove refs/original/* and do git-gc. HTH -- Jakub Narebski Poland ShadeHawk on #git -- 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
