On Tue, Jul 12, 2011 at 09:38:44PM +0200, Clemens Buchacher wrote: > > I'm not sure there's a general solution to that. You can't keep the > > commit you want intact, because you are rebasing and therefore building > > on top of the other broken commit. So in a history like: > > > > B'--C' > > / > > A--B--C > > > > You really want to perform the transformation of B to B', but on top of > > C (i.e., "git checkout C; git diff B' B | git apply"). But if B and C > > are textually related, it's going to conflict horribly. And I don't > > think there is a general solution short of a darcs-style patch algebra. > > FWIW, I tried this in darcs and it has exactly the same problem. It has been a long time since I've looked at darcs, but from my recollection, it will only work with specific patch types. That is, it works if B and C are commutative. For text patches that touch the same area, that is not the case. But if "B" were a token-renaming patch, for example, I think it might work. Anyway, that is not really relevant to git. I think we decided long ago that being simple and stupid about the content changes (i.e., blob A became blob B) is better in general, even when there are a few corner cases that might have been better off the other way. > It does have better granularity when detecting changes. For > example, it will recognize the changes of B' in B, even if B > contains non-conflicting hunks on top of the changes in B'. Git > only recognizes identical commits, and this is something where we > could improve without too much difficulty (think per-hunk > patch-ids). I'd be curious to see an example worked out. In my experience, even if something like patch-ids don't match, it's not a big deal for the hunks that do match, because when we get to the actual content merge, we will realize that both sides made the same change to that hunk. So it's not like you are getting unrelated conflicts; whatever small part of the diff made the patch-id different will be the part where you get the conflict, and the should merge cleanly. Having said something so general, I'm sure there is probably some corner case that proves me wrong. -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