On Jan 7, 2010, at 1:22 PM, Christian MICHON wrote: > I recall asking a similar question in 2008, and the answer was to look > at "git graft" and use "git filter-branch" to recreate history. Thanks, I've tried that and I recall that filter-branch wasn't willing to rewrite just the recent history - at least in started going over all 100k revisions at a very slow pace. I'm still unsure how, after the filter-branch, I would have some ancestor from the B series so that future pulls from the remote work, while having an ancestor from A, to make sure I can continue merging into C. If history is rewritten, I'll get new revisions and lose ancestors. I'm beginning to thing that the cutting and pasting I'd like is conceptually impossible. So what one would need is to specify a "silent parent" for a revision that is relevant w.r.t. future three-way merges, but indicates that the history behind the silent parent is irrelevant and shouldn't be shown in a git-log. The runaway parent would be guaranteed to _not_ contribute any content to the tree of the child revision, as is the case with a "merge ours". This could be implemented as a way to mark a parent as silent (checked by git-log at least), but one could also allow for an empty commit that, while having a normal parent, clears out the tree. Let me know if this idea is completely crazy. -- 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