git-rerere vs rebase --skip

git-rerere vs rebase --skip

[Mike Hommey]

Hi,

In one of my workflows, I constantly rebase topic branches on top of new
upstream imports. As there are several upstream import branches, I have
similar topic branches on top of different imports.
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.

Mike

Re: git-rerere vs rebase --skip

[Junio C Hamano]

Mike Hommey <mh@glandium.org> 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.