From: Elijah Newren Date: Wed, 13 May 2020 03:54:43 GMT Subject: Re: [PATCH v2 1/5] rebase -i: add --ignore-whitespace flag Message-ID: In-Reply-To: <20200429102521.47995-2-phillip.wood123@gmail.com> Sorry for taking so long to get back to you, and thanks for pushing this forward. On Wed, Apr 29, 2020 at 3:26 AM Phillip Wood wrote: > > From: Rohit Ashiwal > > Rebase is implemented with two different backends - 'apply' and 'merge' > each of which support a different set of options. In particuar the apply > backend supports a number of options implemented by 'git am' that are > not available to the merge backend. As part of an on going effort to > remove the apply backend this patch adds support for the > --ignore-whitespace option to the merge backend. This option treats > lines with only whitespace changes as unchanged and is implemented in > the merge backend by translating it to -Xignore-space-change. > > Signed-off-by: Rohit Ashiwal > Signed-off-by: Phillip Wood > --- > Documentation/git-rebase.txt | 12 +++- > builtin/rebase.c | 19 ++++-- > t/t3422-rebase-incompatible-options.sh | 1 - > t/t3436-rebase-more-options.sh | 86 ++++++++++++++++++++++++++ > 4 files changed, 111 insertions(+), 7 deletions(-) > create mode 100755 t/t3436-rebase-more-options.sh > > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt > index f7a6033607..d060c143e6 100644 > --- a/Documentation/git-rebase.txt > +++ b/Documentation/git-rebase.txt > @@ -422,8 +422,16 @@ your branch contains commits which were dropped, this option can be used > with `--keep-base` in order to drop those commits from your branch. > > --ignore-whitespace:: > + Behaves differently depending on which backend is selected. I still don't like this wording; it defers answering the question, implies that the difference is intentional, and most importantly provides no context about *intended* behavior. I tried to communicate this to Rohit multiple times, but he seemed to fixate on and highlight the differences in a way that made them sound like they were by design, rather than highlighting the intent we want to move towards and mentioning that this patch gets us most the way there. As far as I can tell, the --ignore-whitespace and -Xignore-space-change were always meant to do the same thing: ignore differences in whitespace when doing so can avoid conflicts. In case anyone isn't sure about my assertion that these were always meant to do the same thing: * apply aliases --ignore-whitespace and --ignore-space-change; they meant the same thing * commit f008cef4ab ("Merge branch 'jc/apply-ignore-whitespace'", 2014-06-03) says that apply's --ignore-space-change wasn't behaving consistently with diff's --ignore-space-change * diff's --ignore-space-change goes through xdiff's XDL opts, much like merge-recursive does. Further, the original commit that introduced these xdiff options to merge-recursive, 4e5dd044c6 ("merge-recursive: options to ignore whitespace changes", 2010-08-26), it is clear that: * he only cared about ignore-space-at-eol and implemented ignore-space-change at the same time only for completeness * it wouldn't matter to his usecase if whitespace-only changes were stripped, thus he wouldn't have spotted the bug it has * the wording also suggests these options were picked to match options of the same name elsewhere in git I would rather we said something like: Ignore whitespace differences when trying to reconcile differences. Currently, each backend implements an approximation of this behavior: > ++ > +apply backend: When applying a patch, ignore changes in whitespace in > +context lines. Maybe add something like: (Unfortunately, this means that if the "old" lines being replaced by the patch differ only in whitespace from the existing file, you will get a merge conflict instead of a successful patch application.) > ++ > +merge backend: Treat lines with only whitespace changes as unchanged > +when merging. Maybe add something like: (Unfortunately, this means that any patch hunks that were intended to modify whitespace and nothing else will be dropped, even if the other side had no changes that conflicted.) > + > --whitespace=