On Thu, Jan 7, 2010 at 4:16 PM, David Reitter <david.reitter@xxxxxxxxx> wrote: > 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. Hmm, this is pretty nasty. Essentially, you want your repo to include both sets of commits (so that it doesn't try to re-merge in the other commits later), but you don't want to *see* them in git log. Basically, you want git log to lie to you :) Luckily, it already has this ability: it's called history simplification :) Try this in your merged repo: git log . (note the '.'). Without the dot, git log doesn't simplify any history, and you get every change. With the dot, it shows only commits that had a tangible effect on the file in question (in this case, the top directory, which includes *everything*). Thus, a "git merge -s ours" gets eliminated. Beware that it might eliminate other equally non-impactful commits, however. The same trick also works with gitk. Have fun, Avery -- 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