From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Wed, 06 Feb 2008 01:00:29 GMT
Subject: Re: rebase -i and --whitespace, was Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)
Message-ID: <alpine.LSU.1.00.0802060058550.8543@racer.site>
In-Reply-To: <7vir137yvx.fsf@gitster.siamese.dyndns.org>

Hi,

On Tue, 5 Feb 2008, Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > So it means that synopsis should, instead of current (pre-patch)
> >
> > 'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
> >         [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
> >         [--onto <newbase>] <upstream> [<branch>]
> >
> > should read
> >
> > 'git-rebase' [-v | --verbose]  [-p | --preserve-merges]
> >         [{-i | --interactive} | [-C<n>] [ --whitespace=<option>] [-m | --merge]]
> >         [--onto <newbase>] <upstream> [<branch>]
> >
> > or perhaps even separated into interactive / non-interactive merge?
> 
> I think the reality is:
> 
>  * -i ignores the lack of -m (i.e. do not use the slow "merge");
> 
>  * Rebase with -m cannot use -C<n> and --whitespace (hence -i
>    because it forces -m);
> 
>  * -p is only meaningful when using -m;

Even worse, AFAIR -p only works with -i.

> Three possible courses of actions are:
> 
>  (1) fix merge codepath (this is involved --- we would need to
>      teach xdl_merge() to honor --whitespace={warn|error|fix}
>      and -C<n>); or
> 
>  (2) fix -i so that it does not force -m; or
> 
>  (3) adjust the description to reality.
> 
> Obviously the easiest would be to document the behaviour as-is,
> but I suspect (2) would be the best practical solution if we
> wanted to have any improvement compared to the current
> situation.

Granted.  A long time ago, I started making a builtin from rebase/am, but 
I got sidetracked pretty early.

However, I think that (2) and builtinification are pretty related, and can 
be done in one go.

Ciao,
Dscho