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

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

Hi,

On Sun, 25 Jan 2009, Jakub Narebski wrote:

> On Sun, 25 Jan 2009, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > So maybe I answered my question myself:
> > >
> > > 	merge parents $sha1 [$sha1...] original $sha1 $msg
> > 
> > When you are reparenting, how would original commit get in the 
> > picture? You wouldn't want the resulting merge to claim it merged X 
> > (which would be what's in original's commit log) when in fact it now 
> > merged Y because the user reparented it, would you?
> 
> Well, the subject part of merge (with merged branches names) shouldn't, 
> I guess, change. The summary (shortlog) part might, or perhaps even 
> should following rewrite (if it was present here).
> 
> But there is one issue I am wondering about: could we pick up _merge_ 
> _resolution_? So if you have evil merge, and the change is for example 
> splitting commits without visible final changes, or just changing some 
> commit message before merge, it would get recreated without problems?

Nanako had a script at some stage; I would prefer an subcommand to "git 
rerere" which reconstructs the whole merge in-memory, and then records the 
conflict's resolution.

However, I really think you are getting ahead of yourself.  That is by no 
means something we want to have in rebase -p.  And even then, it would 
have to be non-automatic, i.e the user has to check the resolution.

We _know_ that git rerere does a fine job most of the time, almost all of 
the exceptions to be found when working with rebase -i extensively, as you 
are prone to take different decisions during development.

Ciao,
Dscho