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

From: Sam Vilain <[email-masked]>
Date: Fri, 25 Jan 2008 10:14:17 +1300

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.