Elvis Pranskevichus <el(at)prans(dot)net> wrote:
> Instead of filtering non-merge commits I would suggest doing git
> rebase on the latest revision of the old git repo. That way you
> will get a set of commits that should apply cleanly. The reason
> it is failing now is that it is impossible for git am to do a
> 3-way merge without the original git objects, which are obviously
> not available in the new repo.
Well, that didn't work much better. It applied, but it started in
June, and the "big" file, which has been in constant flux since
January suddenly springs into existence in July. :-( The last few
commits look right, but it gets pretty trashy pretty quickly before
that.
What *did* work is to take a fresh of the new repo, branch it as of
the point in time that I created my original branch, and take the
first mbox entry of the 167, which starts like this:
>From 07ea78aaafe22cbbb0ffdedbfcf78404abbdbc70 Mon Sep 17 00:00:00
2001
From: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Date: Fri, 8 Jan 2010 15:39:12 -0600
and change the first line to point to the point at which this was
applied:
>From 369494e41fe408f103884032f477555ba134a0a8 Fri Jan 8 09:06:05
2010
That applies fine. It's an encouraging start, but I'm not clear on
exactly what I have to do to get the rest of these commits merged in
with commits from the master branch cleanly. Some fix-up work is OK
with me. Do I need to look at the old log and manually interleave
merges to the branch and manual commits in the original pattern to
make such a scheme work?
-Kevin