Jeff King <peff@xxxxxxxx> writes: > ... But with a commit no top, you get: > > <<<<<<< HEAD > two > ======= > one > >>>>>>> one > > which looks like you are reverting, because of course you are building > on top of the finished series. Exactly. > $ git rebase master topic > Applying: one > Using index info to reconstruct a base tree... > Falling back to patching base and 3-way merge... > Auto-merging file > CONFLICT (content): Merge conflict in file > Failed to merge in the changes. > Patch failed at 0001 one > > hint: this commit may already be in upstream as 1234abcd; > hint: the differences between that commit and this one are: > > diff --git a/file b/file > --- a/file > +++ b/file > @@ -1 +1 @@ > -modified one > +one > > When you have resolved this problem run "git rebase --continue". > If you would prefer to skip this patch, instead run "git rebase --skip". > To restore the original branch and stop rebasing run "git rebase --abort". 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). The conflict resolution to come up with such an incremental change is very painful. You have to avoid the "s/two/one/" revert, and you have to keep the "s/modified one/one" revert, and you need to know which hunks are conflicting due to what (i.e. the former is because a patch similar to the one you haven't replayed in this rebase session is already in upstream, the latter is the upstream tweaked the current patch you are looking at in a way you do not agree with). I do not have a good idea to solve this in mind yet. -- 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