Thread (12 messages) 12 messages, 5 authors, 2016-06-15

Re: rebase -i and --whitespace, was Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)

flat view

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:10

Jakub Narebski [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help