git rebase --rebase-merges information loss (and other woes)

[ydirson@free.fr]

I've been going through a couple of "rebase -i -r" lately, and would
like to share a couple of thoughts, starting with something looking
like a bug.

1. when a merge has been done with "-s ours", rebase replays it without
any special options, I proceed with the manual resolution, and if I just
--continue, the rebase mechanism believes I want to drop the commit, which
could not be more wrong.  I can still be careful myself, and use "git commit
--allow-empty" before --continue, but this feels awkward.

Is there any compelling reason not record the merge here ?


2. more generally, when a merge has been done with special options, it
would be a useful help in solving conflicts if rebase could use the same
options.  Maybe we could allow the rebase "merge" instruction to use more
merge options.  The user would still have to edit the instruction sheet
manually for those, however, and we could then want "rebase -i" to fill
them automatically, but that would seem to require recording the merge
options somewhere to start with - maybe in a note.


3. while it's made clear that any conflict resolution and amendments
have to be redone, maybe we could provide some support for a common
use case, namely "sink that commit/fixup down".  The conflict
resolution would then be like "checkout $OLD && cherry-pick -n $FIXUP".

Maybe this could be activated by a merge option in rebase-interactive
instructions, like "merge -C$OLD --fixup $F1 --fixup $F2".

Would that seem reasonable ?

-- 
Yann