Jakub Narebski <jnareb@xxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
