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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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.