From: Phillip Wood Date: Thu, 14 May 2020 09:47:47 GMT Subject: Re: [PATCH v2 1/5] rebase -i: add --ignore-whitespace flag Message-ID: In-Reply-To: On 13/05/2020 04:54, Elijah Newren wrote: > Sorry for taking so long to get back to you, and thanks for pushing > this forward. Thanks for taking a look at this series > > 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.) Thanks for the suggestions, I'll incorporate them into the re-roll. Best Wishes Phillip >> + >> --whitespace=