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. - 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
