On Mon, Jul 11, 2011 at 08:03:04PM -0400, Jeff King wrote: > On Mon, Jul 11, 2011 at 04:21:54PM -0700, Junio C Hamano wrote: > > > Actually I do not think identifying the ones that can safely skipped is > > such a big issue. The case I am most concerned about is when you see that > > "two reverted back to one" (which you obviously want to avoid, to keep the > > effect of the commit the upstream has to have "two" on that line), but at > > the same time when you do not agree with the change that the upstream took > > for the _current commit_ you are replaying (i.e. you want the final result > > to have "one", not "modified one" which the upstream has applied). > > 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 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). But if the changes in B and B' have conflicts, then darcs will present the user with the options B' and C, which looks like we were trying to revert C, just like it does with git. Clemens -- 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