On Mon, Mar 03, 2008 at 07:55:21AM +0100, Mike Hommey wrote: > Starting with a history like this: > > G---H > / > A---B---C---D---E---F > > Where A, B, C, ... are *trees*, not commits, the expected result would > be > > A---B---C---D---E---F---G---H > > This is what might happen with git-filter-branch if you graft G to F. (I > don't know if it actually works in cases where the grafted commit had a > parent, originally) Ah, OK. That makes some sense, and I think would work if "git merge-ours" actually did a "git read-tree && git checkout-index" on the "us" parameter instead of just assuming that the working tree is what is desired. I'm still not sure it is all that useful in practice. -Peff -- 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
