From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 05 Feb 2008 23:43:30 GMT
Subject: Re: rebase -i and --whitespace, was Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)
Message-ID: <7vir137yvx.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200802041642.52088.jnareb@gmail.com>

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;

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.