Re: Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

JM Ibanez wrote:

Actually, I forgot to mention that I already have grafts between the two
to track merges I performed previously. So, in fact, the history looks
like something this:

     A -- B -- C -- D -- E -- a -- b -- c -- d -- e -- f -- m3
                         \         \          \             /
                          \         \          \   /-------+
     A'-- B'-- C'-- D'-- E'-- x -- y -- m1-- z -- m2


where x, m1, m2, and m3 are squashed merge commits + grafts.

After git filter-branch with a graft of x to E, I get x having two
parents as what is needed *but* because the parent IDs are part of the
commit object, I now get x' y', etc, something like this:



     A -- B -- C -- D -- E -- a -- b -- c -- ...
                         |         |
                         |         |
                         |         +--- m1'- z'-- m2' -- ...
                         \         \
                          \         \
                           -- x -- y -- m1-- z -- ...


sort of. In any case, I get duplicate commits of m1, z, etc. after the
primary graft point. Is this expected?

I think you need to use a parent filter that looks up the old commit ID
in the grafts, and adjusts the parents accordingly.  I don't think I'd
be able to nail it down any further than that without actually trying.

I think the intent of git filter-branch's grafting support is that this
shouldn't happen, so if you can produce a test case then the bug can
likely be fixed.

Sam.