Elvis Pranskevichus <e...@prans.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.gritt...@wicourts.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers