Re: [PATCH 0/4] reworking git-rebase

Sven Verdoolaege [off-list ref] writes:

Will the reworked rebase still support this use or is there
a better way to do this ?

I think it is reasonable to assume that you would not usually
want to muck with commits that cleanly replay.  Further, you
would do that kind of irregular replaying (e.g. not replaying
all of them, or skipping some of them) only after one of the
commit fails to cleanly replay, and you would not mind (rather,
you would be happy) to keep the commits that have been already
cleanly replayed, and would start playing games like dropping
patches after the one that fails.

If the above is a reasonable assumption, then, the answer is
yes.  And if not, you can always resort to manual
"git-format-patch -k", followed by file editing, followed by
"git am -k -3", to reorder patches.  Although at that point you
should either be looking at StGIT or doing a just plain merge.

When "git am" first fails, all the rest of patches are kept in
.dotest/.  And after fixing up the failed one in your working
tree, you can restart it with interactive flag, like this: "git
am -i -3 --resolved".  It lets you tell it skip one patch, or
not apply any of the rest.  [Side note: it might be a good idea
to make --resolved imply --interactive].

Quite often, the reason why a rebased patch does not apply is
because an equivalent patch (or a set of patches whose
cumulative effect is the same as one of your patches) has been
thrown in to the new "master".  "git cherry" is too dumb (IOW,
git-patch-id is too strict) to notice such cases.  "git am -3"
first tries to do git-apply, and when it fails (and it will fail
if your working tree already has what the patch would do), it
falls back to 3-way merge by picking up the pre-image blob ids
recorded in the patch.  When seeing an already applied patch,
this 3-way merge often results in the same tree as you started.
When "git am" notices the situation, it throws away that patch
(it says "already applied") automatically.