Heads up: rebase -i -p will be made sane again

Dear list,

I am progressing to a point where I am almost comfortable to send the patch series; I want to use the thing myself first, and I want to fix a design bug.

As always, my code is public, but will be rebased frequently. You have been warned.

BTW I am really sorry for the state I left the --preserve-merges code for a long time. Originally, it was never meant to be used interactively, and that shows sorely.

As for the design bug I want to fix: imagine this history:

  ------A
 /     /
/     /
---- B
\     \
 \     \
  C-----D-----E = HEAD

A, C and D touch the same file, and A and D agree on the contents.

Now, rebase -p A does the following at the moment:

  ------A-----E' = HEAD
 /     /
/     /
---- B

In other words, C is truly forgotten, and it is pretended that D never happened, either. That is exactly what test case 2 in t3410 tests for [*1*].

This is insane.

So after my rebase -i -p revamp, this will happen instead: in the interactive version you will get the script

	pick C
	merge parents B' original D
	pick E

In the non-interactive version -- or if you change nothing, in the interactive version, too -- this will lead to a conflict while picking C.

As it should.

Ciao, Dscho

[*1*] The code in t3410 was not really easy to read, even if there was an explanation what it tried to do, but the test code was inconsitent, sometimes tagging, sometimes not, sometimes committing with -a, sometimes "git add"ing first, yet almost repetitive.

In my endeavor not only to understand it, and either fix my code or the code in t3410, I refactored it so that others should have a much easier time to understand what it actually does.