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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 25, 2009, 14:17 UTC
Message-ID: <alpine.DEB.1.00.0901251509550.14855@racer>
In-Reply-To: <glhqdi$tec$1@ger.gmane.org>

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:

Show 13 quoted lines

> 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