Mike Hommey <mh@xxxxxxxxxxxx> writes: > When rebasing the topic branches, I can hit conflict resolution that I > already had to do for other topic branches on another upstream import > branch. Here, git rerere is very helpful. But sometimes, the conflict > resolution is just to skip the patch, because it was incorporated > upstream in a way that git doesn't detect, or it was obsoleted, or > whatever. In such cases, git rerere is not being helpful because it > doesn't store any information about that, and I have to check again if > that's an actual conflict to solve or a patch to skip again. > > It would be helpful if there was a rebase --skip mode that would tell > rerere to record that the resolution *is* --skip. That is like saying "my hammer is very helpful when I want to hit nails, but sometimes I wish it helped me with screws". The only thing "rerere" does is to remember the shape of the conflicted state and desired resolution _per_ _file_. It does not tell "rebase" what to do next (you do, via "git add -u" followed by "git rebase --continue"). Presumably, you _could_ run "git checkout HEAD $path" followed by "git rerere" to record that a particular shape of the conflicted state should resolve to what you already have in the HEAD commit, so that the same conflict that happens in future rebases automatically resolve to a no-op for these conflicted paths, and telling "rebase" to continue via the same "add -u && rebase --continue" might notice that there is no change, and its "skip empty" logic might kick in. But I wouldn't blindly recommend it. If a change you are replaying has two paths, one that somehow cleanly merges, and the other that conflicts because you do have an equivalent change (and more) in the updated HEAD, letting "rebase" continue that way would record only the changes to the first path while ignoring the other one, which may or may not be what you want. -- 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