Re: Heads up: major rebase -i -p rework coming up

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

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1040 bytes --]

Hi,

[please do not forget to Cc: me; today is a slow day, so I did not miss 
 your mail, but that is definitely not true on other days.]

On Sun, 25 Jan 2009, Jakub Narebski wrote:

> Johannes Schindelin wrote:
> 
> >> Hmm.  You're right, that is not really intuitive.  How about
> >> 
> >>       merge (B) A # Merge...
> >> 
> >> instead?
> > 
> > Or even better:
> > 
> >         merge B parent A' # Merge...
> 
> merge B with A' # Merge... 

No, that does not catch the meaning.

B is the _original_ merge commit.  So it actually knows what parents it 
has, but we want to give the user the freedom to change those parents.

The first parent is easy: this will be HEAD at that stage.

The other parents will be relatively easy: just replace A' by something 
else.

_However_ now that the merge commit B will be _redone_, we _still_ want to 
be able to refer to it later in the rebase script.  Therefore, rebase has 
to know that we _redid_ B at this stage.

Another idea:

	merge B Merge bla/blub
	parent A' bla/blub

Hmm?

Ciao,
Dscho