{"thread":{"id":"65626","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","startedAt":"2026-05-12T20:56:32Z","lastAt":"2026-06-08T11:04:37Z","messageCount":14,"participants":["Michael Montalbo","Vincent Lefevre","Junio C Hamano","Phillip Wood","Johannes Sixt","Chris Torek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"543218","messageId":"CAC2QwmKRyYfE+30Fh75gvAEmJjk8g-3k+G=RDiEJ-KGNExAEow@mail.gmail.com","threadId":"65626","inReplyTo":null,"subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-05-12T20:56:19Z","receivedAt":"2026-05-12T20:56:32Z","isPatch":false,"body":"On Sat, 9 May 2026 17:55:26 +0200, Vincent Lefevre wrote:\n> For wdiff, it is just described as \"display word differences between\n> text files\", and it does exactly that. For instance, if there are no\n> differences in words, it shows no differences.\n>\n> For git with the --word-diff, there is actually no documentation,\n> except the use of \"changed words\" and \"word diff\". No mention of\n> line diff at all! So this is quite confusing.\n\nMaybe something like this would be worth adding to the docs:\n\n-- >8 --\ndiff --git a/Documentation/diff-options.adoc b/Documentation/diff-options.adoc\nindex 8a63b5e164..665473e61a 100644\n--- a/Documentation/diff-options.adoc\n+++ b/Documentation/diff-options.adoc\n@@ -457,6 +457,11 @@ endif::git-diff[]\n +\n Note that despite the name of the first mode, color is used to\n highlight the changed parts in all modes if enabled.\n++\n+Word diff works by finding word-level changes within each hunk of\n+the line-level diff.  The line-level alignment determines which\n+changed lines are compared to each other, which can affect the\n+word-level output.\n\n `--word-diff-regex=<regex>`::\n        Use _<regex>_ to decide what a word is, instead of considering\n-- >8 --\n"},{"id":"543220","messageId":"20260512211707.GB1516810@qaa.vinc17.org","threadId":"65626","inReplyTo":"CAC2QwmKRyYfE+30Fh75gvAEmJjk8g-3k+G=RDiEJ-KGNExAEow@mail.gmail.com","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Vincent Lefevre","fromEmail":"vincent@vinc17.net","sentAt":"2026-05-12T21:17:07Z","receivedAt":"2026-05-12T21:17:15Z","isPatch":false,"body":"On 2026-05-12 13:56:19 -0700, Michael Montalbo wrote:\n> Maybe something like this would be worth adding to the docs:\n[...]\n> +Word diff works by finding word-level changes within each hunk of\n> +the line-level diff.  The line-level alignment determines which\n> +changed lines are compared to each other, which can affect the\n> +word-level output.\n[...]\n\nYes, this would be useful.\n\n-- \nVincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>\n100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>\nWork: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)\n"},{"id":"543247","messageId":"CAC2QwmKxiUczUdsb6H7_fnxSwZJS6SAh_moL=4x-FGNNpvm6xQ@mail.gmail.com","threadId":"65626","inReplyTo":"20260512211707.GB1516810@qaa.vinc17.org","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-05-13T15:52:39Z","receivedAt":"2026-05-13T15:52:52Z","isPatch":false,"body":"On 2026-05-12 21:17 UTC, Vincent Lefevre wrote:\n> Yes, this would be useful.\n\nI've submitted a patch for this:\nhttps://lore.kernel.org/git/pull.2113.git.1778686956622.gitgitgadget@gmail.com/T/#u\n\nOn Tue, May 12, 2026 at 2:17 PM Vincent Lefevre <vincent@vinc17.net> wrote:\n>\n> On 2026-05-12 13:56:19 -0700, Michael Montalbo wrote:\n> > Maybe something like this would be worth adding to the docs:\n> [...]\n> > +Word diff works by finding word-level changes within each hunk of\n> > +the line-level diff.  The line-level alignment determines which\n> > +changed lines are compared to each other, which can affect the\n> > +word-level output.\n> [...]\n>\n> Yes, this would be useful.\n>\n> --\n> Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>\n> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>\n> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)\n"},{"id":"543288","messageId":"xmqq8q9migqk.fsf@gitster.g","threadId":"65626","inReplyTo":"CAC2QwmKRyYfE+30Fh75gvAEmJjk8g-3k+G=RDiEJ-KGNExAEow@mail.gmail.com","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-05-14T07:37:39Z","receivedAt":"2026-05-14T07:37:42Z","isPatch":false,"body":"Michael Montalbo <mmontalbo@gmail.com> writes:\n\n> @@ -457,6 +457,11 @@ endif::git-diff[]\n>  +\n>  Note that despite the name of the first mode, color is used to\n>  highlight the changed parts in all modes if enabled.\n> ++\n> +Word diff works by finding word-level changes within each hunk of\n> +the line-level diff.  The line-level alignment determines which\n> +changed lines are compared to each other, which can affect the\n> +word-level output.\n\nThe added text may not say anything wrong, but I am not sure how it\nhelps the end user to know the way machinery works internally.\n\n"},{"id":"543292","messageId":"20260514095522.GA159111@qaa.vinc17.org","threadId":"65626","inReplyTo":"xmqq8q9migqk.fsf@gitster.g","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Vincent Lefevre","fromEmail":"vincent@vinc17.net","sentAt":"2026-05-14T09:55:22Z","receivedAt":"2026-05-14T09:55:32Z","isPatch":false,"body":"On 2026-05-14 16:37:39 +0900, Junio C Hamano wrote:\n> Michael Montalbo <mmontalbo@gmail.com> writes:\n> \n> > @@ -457,6 +457,11 @@ endif::git-diff[]\n> >  +\n> >  Note that despite the name of the first mode, color is used to\n> >  highlight the changed parts in all modes if enabled.\n> > ++\n> > +Word diff works by finding word-level changes within each hunk of\n> > +the line-level diff.  The line-level alignment determines which\n> > +changed lines are compared to each other, which can affect the\n> > +word-level output.\n> \n> The added text may not say anything wrong, but I am not sure how it\n> helps the end user to know the way machinery works internally.\n\nPerhaps only the first sentence should be kept and that the following\nshould be added: \"Because of that, using the --ignore-space-change\noption is recommended.\"\n\nNote: Earlier in the discussion, Johannes Sixt suggested -w\n(--ignore-all-space), but this is wrong, as\n\n  git diff --word-diff -w <(printf foo) <(printf \"f o o\")\n\ngives no differences while one has 1 word \"foo\" vs 3 words \"f o o\".\n\nHowever, --ignore-space-change is actually not even sufficient\nsince\n\n  git diff --ignore-space-change <(printf \"foo bar\") <(printf \"foo\\nbar\")\n\nfinds differences though there are only space changes (thus this\nmay affect hunks in case --word-diff would be used too). However,\nI suppose that the cases where --word-diff --ignore-space-change\nwould not give a \"real word diff\" would be quite rare in practice.\n\n-- \nVincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>\n100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>\nWork: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)\n"},{"id":"543399","messageId":"d888553a-8a99-4c79-b720-a562ac9900e2@gmail.com","threadId":"65626","inReplyTo":"20260514095522.GA159111@qaa.vinc17.org","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-05-15T13:22:59Z","receivedAt":"2026-05-15T13:23:03Z","isPatch":false,"body":"On 14/05/2026 10:55, Vincent Lefevre wrote:\n> On 2026-05-14 16:37:39 +0900, Junio C Hamano wrote:\n>> Michael Montalbo <mmontalbo@gmail.com> writes:\n>>\n>>> @@ -457,6 +457,11 @@ endif::git-diff[]\n>>>   +\n>>>   Note that despite the name of the first mode, color is used to\n>>>   highlight the changed parts in all modes if enabled.\n>>> ++\n>>> +Word diff works by finding word-level changes within each hunk of\n>>> +the line-level diff.  The line-level alignment determines which\n>>> +changed lines are compared to each other, which can affect the\n>>> +word-level output.\n>>\n>> The added text may not say anything wrong, but I am not sure how it\n>> helps the end user to know the way machinery works internally.\n> \n> Perhaps only the first sentence should be kept and that the following\n> should be added: \"Because of that, using the --ignore-space-change\n> option is recommended.\"\n> \n> Note: Earlier in the discussion, Johannes Sixt suggested -w\n> (--ignore-all-space), but this is wrong, as\n> \n>    git diff --word-diff -w <(printf foo) <(printf \"f o o\")\n> \n> gives no differences while one has 1 word \"foo\" vs 3 words \"f o o\".\n> \n> However, --ignore-space-change is actually not even sufficient\n> since\n> \n>    git diff --ignore-space-change <(printf \"foo bar\") <(printf \"foo\\nbar\")\n> \n> finds differences though there are only space changes (thus this\n> may affect hunks in case --word-diff would be used too). However,\n> I suppose that the cases where --word-diff --ignore-space-change\n> would not give a \"real word diff\" would be quite rare in practice.\n\nI'm a bit wary of recommending -w unconditionally in case it gives \nunexpected results. I've not really found there to be a problem using \n--word-diff when reviewing code patches. In the examples you gave we'd \nideally fix the problem by computing a single word-diff per hunk from \nthe line based diff rather than splitting the hunk at each context line. \nI think we'd probably want to exclude the leading and trailing context \nto keep the hunk header accurate but we'd get better results by \ncalculating the word diff of everything in the hunk between the first \nchanged line and the last changed line.\n\nThanks\n\nPhillip\n\n"},{"id":"543499","messageId":"CAC2QwmKORPnsmV4SM_CnmhrbF+X754ae-n9m1fgjvVsL9d-wzg@mail.gmail.com","threadId":"65626","inReplyTo":"xmqq8q9migqk.fsf@gitster.g","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-05-18T03:30:38Z","receivedAt":"2026-05-18T03:30:51Z","isPatch":false,"body":"On Thu, May 14, 2026 at 12:37 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Michael Montalbo <mmontalbo@gmail.com> writes:\n>\n> > @@ -457,6 +457,11 @@ endif::git-diff[]\n> >  +\n> >  Note that despite the name of the first mode, color is used to\n> >  highlight the changed parts in all modes if enabled.\n> > ++\n> > +Word diff works by finding word-level changes within each hunk of\n> > +the line-level diff.  The line-level alignment determines which\n> > +changed lines are compared to each other, which can affect the\n> > +word-level output.\n>\n> The added text may not say anything wrong, but I am not sure how it\n> helps the end user to know the way machinery works internally.\n>\n\nI see what you mean. Maybe the doc should focus more on calling out\nthe user-facing implication:\n\n  `--word-diff` finds word-level changes within each hunk of the\n  line-level diff, so changes that only affect whitespace may still\n  appear in the output.\n\nI've intentionally omitted a whitespace workaround recommendation for\nnow given the ongoing discussion in the thread.\n"},{"id":"543500","messageId":"89224cb5-27b1-45b6-93d8-a0ad5e2447a2@kdbg.org","threadId":"65626","inReplyTo":"CAC2QwmKORPnsmV4SM_CnmhrbF+X754ae-n9m1fgjvVsL9d-wzg@mail.gmail.com","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2026-05-18T07:30:03Z","receivedAt":"2026-05-18T07:30:13Z","isPatch":false,"body":"Am 18.05.26 um 05:30 schrieb Michael Montalbo:\n> On Thu, May 14, 2026 at 12:37 AM Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>> Michael Montalbo <mmontalbo@gmail.com> writes:\n>>\n>>> @@ -457,6 +457,11 @@ endif::git-diff[]\n>>>  +\n>>>  Note that despite the name of the first mode, color is used to\n>>>  highlight the changed parts in all modes if enabled.\n>>> ++\n>>> +Word diff works by finding word-level changes within each hunk of\n>>> +the line-level diff.  The line-level alignment determines which\n>>> +changed lines are compared to each other, which can affect the\n>>> +word-level output.\n>>\n>> The added text may not say anything wrong, but I am not sure how it\n>> helps the end user to know the way machinery works internally.\n>>\n> \n> I see what you mean. Maybe the doc should focus more on calling out\n> the user-facing implication:\n> \n>   `--word-diff` finds word-level changes within each hunk of the\n>   line-level diff, so changes that only affect whitespace may still\n>   appear in the output.\nI don't know what this paragraph is trying to explain. I don't see how\nthis would explain Vincent's observed word-diff.\n\nThe thing is, \"word-diff\" is such a descriptive name for the operation\nthat it is difficult to find a description that is even better. The\nmanual page doesn't even give it a try. It defers to --word-diff-regex\nright away, which then only talks about low-level details and doesn't\nattempt to give a higher-level description what a word-diff is.\n\nI don't think you can summarize the algorithm in a single sentence. But\nthen I have to ask: why write it down anyway? How does it help the\nreader? Only so that they are able to derive an explanation for a\nparticular observed output? Would it have saved Vincent to write a bug\nreport?\n\nIf we document the algorithm in such detail, we cast it in stone. I\nwouldn't want to paint ourselves into that corner.\n\n-- Hannes\n\n"},{"id":"543581","messageId":"CAC2Qwm+BLNf-2kvePKNF-FKQX3raOBzSRmwd0ZEdzmo8TqkMGA@mail.gmail.com","threadId":"65626","inReplyTo":"89224cb5-27b1-45b6-93d8-a0ad5e2447a2@kdbg.org","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-05-19T02:07:21Z","receivedAt":"2026-05-19T02:07:35Z","isPatch":false,"body":"On Mon, May 18, 2026 at 12:30 AM Johannes Sixt <j6t@kdbg.org> wrote:\n>\n> Am 18.05.26 um 05:30 schrieb Michael Montalbo:\n> > On Thu, May 14, 2026 at 12:37 AM Junio C Hamano <gitster@pobox.com> wrote:\n> >>\n> >> Michael Montalbo <mmontalbo@gmail.com> writes:\n> >>\n> >>> @@ -457,6 +457,11 @@ endif::git-diff[]\n> >>>  +\n> >>>  Note that despite the name of the first mode, color is used to\n> >>>  highlight the changed parts in all modes if enabled.\n> >>> ++\n> >>> +Word diff works by finding word-level changes within each hunk of\n> >>> +the line-level diff.  The line-level alignment determines which\n> >>> +changed lines are compared to each other, which can affect the\n> >>> +word-level output.\n> >>\n> >> The added text may not say anything wrong, but I am not sure how it\n> >> helps the end user to know the way machinery works internally.\n> >>\n> >\n> > I see what you mean. Maybe the doc should focus more on calling out\n> > the user-facing implication:\n> >\n> >   `--word-diff` finds word-level changes within each hunk of the\n> >   line-level diff, so changes that only affect whitespace may still\n> >   appear in the output.\n> I don't know what this paragraph is trying to explain. I don't see how\n> this would explain Vincent's observed word-diff.\n>\n\nYeah, I was trying to explain the difference Vincent saw compared to wdiff,\nbut I agree with your criticism. In \"beating around the bush\" regarding\nimplementation details / making a direct comparison to wdiff, it has been\nhard to craft a meaningful message.\n\n> The thing is, \"word-diff\" is such a descriptive name for the operation\n> that it is difficult to find a description that is even better. The\n> manual page doesn't even give it a try. It defers to --word-diff-regex\n> right away, which then only talks about low-level details and doesn't\n> attempt to give a higher-level description what a word-diff is.\n>\n> I don't think you can summarize the algorithm in a single sentence. But\n> then I have to ask: why write it down anyway? How does it help the\n> reader? Only so that they are able to derive an explanation for a\n> particular observed output? Would it have saved Vincent to write a bug\n> report?\n>\n> If we document the algorithm in such detail, we cast it in stone. I\n> wouldn't want to paint ourselves into that corner.\n>\n\nI also agree with this sentiment. I haven't been able to come up with a\nmessage that threads the needle appropriately, so I'm open to dropping\nthe patch or reworking it if others have suggestions.\n\n> -- Hannes\n>\n"},{"id":"543582","messageId":"CAPx1Gvd_FqnsjCkpAA5uy7aDz9oQnWx7WTvKk-kLWemkqF9PsQ@mail.gmail.com","threadId":"65626","inReplyTo":"CAC2Qwm+BLNf-2kvePKNF-FKQX3raOBzSRmwd0ZEdzmo8TqkMGA@mail.gmail.com","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2026-05-19T02:31:35Z","receivedAt":"2026-05-19T02:31:50Z","isPatch":false,"body":"On Mon, May 18, 2026 at 7:11 PM Michael Montalbo <mmontalbo@gmail.com> wrote:\n> Yeah, I was trying to explain the difference Vincent saw compared to wdiff,\n> but I agree with your criticism. In \"beating around the bush\" regarding\n> implementation details / making a direct comparison to wdiff, it has been\n> hard to craft a meaningful message.\n\nMy opinion is: don't do that, just get right to it.\n\n> > If we document the algorithm in such detail, we cast it in stone. I\n> > wouldn't want to paint ourselves into that corner.\n\n> I also agree with this sentiment. I haven't been able to come up with a\n> message that threads the needle appropriately, so I'm open to dropping\n> the patch or reworking it if others have suggestions.\n\nCall it an \"implementation note\" (or, if you like, a \"practical\nconsideration\"?).\nSomething along these lines might work...\n\n  Implementation Note\n\n  The --word-diff option currently operates by taking the same\n  line by line diff that you get without the option, then massaging\n  the result into a word-by-word difference. This may cause an\n  unnecessarily-larger diff than you would see with a more-clever\n  implementation. If and when Git acquires a more-clever\n  implementation, the output may change. Note that this is\n  similar to the --diff-algorithm option, which may change the\n  output.\n\n  Regardless of which algorithm is used, _any_ diff simply shows\n  _a_ way to achieve some particular change. It's impossible for\n  any algorithm to tell whether someone deleted two lines and\n  then put one back exactly as it appeared earlier, saving the\n  resulting text, vs deleting a single line, for instance. Only a\n  keystroke-by-keystroke logger would be able to tell what the\n  human operator actually typed into some editor. Git does\n  not have that information, and having it is not desired.\n\nChris\n"},{"id":"543583","messageId":"xmqqo6ic8564.fsf@gitster.g","threadId":"65626","inReplyTo":"CAPx1Gvd_FqnsjCkpAA5uy7aDz9oQnWx7WTvKk-kLWemkqF9PsQ@mail.gmail.com","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-05-19T03:11:15Z","receivedAt":"2026-05-19T03:11:17Z","isPatch":false,"body":"Chris Torek <chris.torek@gmail.com> writes:\n\n> Call it an \"implementation note\" (or, if you like, a \"practical\n> consideration\"?).\n> Something along these lines might work...\n>\n>   Implementation Note\n>\n>   The --word-diff option currently operates by taking the same\n>   line by line diff that you get without the option, then massaging\n>   the result into a word-by-word difference. This may cause an\n>   unnecessarily-larger diff than you would see with a more-clever\n>   implementation. If and when Git acquires a more-clever\n>   implementation, the output may change. Note that this is\n>   similar to the --diff-algorithm option, which may change the\n>   output.\n>\n>   Regardless of which algorithm is used, _any_ diff simply shows\n>   _a_ way to achieve some particular change. It's impossible for\n>   any algorithm to tell whether someone deleted two lines and\n>   then put one back exactly as it appeared earlier, saving the\n>   resulting text, vs deleting a single line, for instance. Only a\n>   keystroke-by-keystroke logger would be able to tell what the\n>   human operator actually typed into some editor. Git does\n>   not have that information, and having it is not desired.\n>\n> Chris\n\nI understand your frustration in the second paragraph ;-) but let's\nnot go there.  The first paragraph is excellent.  It gives readers a\nclear enough explanation to understand what is happening and stop\ncomplaining where there is nothing to complain about (which is\nalready hinted by the \"Note that\" at the end).\n\n"},{"id":"543748","messageId":"CAC2QwmLXk=CXNo8+Ja0fL5pN1YYMTkh7XHAUwN1c9VxuFhyy4Q@mail.gmail.com","threadId":"65626","inReplyTo":"xmqqo6ic8564.fsf@gitster.g","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-05-20T20:21:33Z","receivedAt":"2026-05-20T20:21:46Z","isPatch":false,"body":"On Mon, May 18, 2026 at 8:11 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Chris Torek <chris.torek@gmail.com> writes:\n>\n> > Call it an \"implementation note\" (or, if you like, a \"practical\n> > consideration\"?).\n> > Something along these lines might work...\n> >\n> >   Implementation Note\n> >\n> >   The --word-diff option currently operates by taking the same\n> >   line by line diff that you get without the option, then massaging\n> >   the result into a word-by-word difference. This may cause an\n> >   unnecessarily-larger diff than you would see with a more-clever\n> >   implementation. If and when Git acquires a more-clever\n> >   implementation, the output may change. Note that this is\n> >   similar to the --diff-algorithm option, which may change the\n> >   output.\n> >\n> >   Regardless of which algorithm is used, _any_ diff simply shows\n> >   _a_ way to achieve some particular change. It's impossible for\n> >   any algorithm to tell whether someone deleted two lines and\n> >   then put one back exactly as it appeared earlier, saving the\n> >   resulting text, vs deleting a single line, for instance. Only a\n> >   keystroke-by-keystroke logger would be able to tell what the\n> >   human operator actually typed into some editor. Git does\n> >   not have that information, and having it is not desired.\n> >\n> > Chris\n>\n> I understand your frustration in the second paragraph ;-) but let's\n> not go there.  The first paragraph is excellent.  It gives readers a\n> clear enough explanation to understand what is happening and stop\n> complaining where there is nothing to complain about (which is\n> already hinted by the \"Note that\" at the end).\n>\n\nThanks for the ideas, Chris. Here is my attempt at synthesizing Chris'\nsuggestions and Junio's feedback:\n\n  The `--word-diff` option operates by taking the same line-by-line\n  diff that is produced without the option and computing\n  word-by-word changes within each hunk.  This may produce a\n  larger diff than a dedicated word-diff tool would.  If Git\n  acquires a different implementation in the future, the output\n  may change.  Note that this is similar to the `--diff-algorithm`\n  option, which may also change the output.\n\nDoes this work?\n"},{"id":"544233","messageId":"CAC2QwmKjr2eiFNPPmERq7n-UjE-SF2vE4eHDanYE-4heWxzQVw@mail.gmail.com","threadId":"65626","inReplyTo":"CAC2QwmLXk=CXNo8+Ja0fL5pN1YYMTkh7XHAUwN1c9VxuFhyy4Q@mail.gmail.com","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-05-28T19:25:01Z","receivedAt":"2026-05-28T19:25:15Z","isPatch":false,"body":"On Wed, May 20, 2026 at 1:21 PM Michael Montalbo <mmontalbo@gmail.com> wrote:\n>\n> On Mon, May 18, 2026 at 8:11 PM Junio C Hamano <gitster@pobox.com> wrote:\n> >\n> > Chris Torek <chris.torek@gmail.com> writes:\n> >\n> > > Call it an \"implementation note\" (or, if you like, a \"practical\n> > > consideration\"?).\n> > > Something along these lines might work...\n> > >\n> > >   Implementation Note\n> > >\n> > >   The --word-diff option currently operates by taking the same\n> > >   line by line diff that you get without the option, then massaging\n> > >   the result into a word-by-word difference. This may cause an\n> > >   unnecessarily-larger diff than you would see with a more-clever\n> > >   implementation. If and when Git acquires a more-clever\n> > >   implementation, the output may change. Note that this is\n> > >   similar to the --diff-algorithm option, which may change the\n> > >   output.\n> > >\n> > >   Regardless of which algorithm is used, _any_ diff simply shows\n> > >   _a_ way to achieve some particular change. It's impossible for\n> > >   any algorithm to tell whether someone deleted two lines and\n> > >   then put one back exactly as it appeared earlier, saving the\n> > >   resulting text, vs deleting a single line, for instance. Only a\n> > >   keystroke-by-keystroke logger would be able to tell what the\n> > >   human operator actually typed into some editor. Git does\n> > >   not have that information, and having it is not desired.\n> > >\n> > > Chris\n> >\n> > I understand your frustration in the second paragraph ;-) but let's\n> > not go there.  The first paragraph is excellent.  It gives readers a\n> > clear enough explanation to understand what is happening and stop\n> > complaining where there is nothing to complain about (which is\n> > already hinted by the \"Note that\" at the end).\n> >\n>\n> Thanks for the ideas, Chris. Here is my attempt at synthesizing Chris'\n> suggestions and Junio's feedback:\n>\n>   The `--word-diff` option operates by taking the same line-by-line\n>   diff that is produced without the option and computing\n>   word-by-word changes within each hunk.  This may produce a\n>   larger diff than a dedicated word-diff tool would.  If Git\n>   acquires a different implementation in the future, the output\n>   may change.  Note that this is similar to the `--diff-algorithm`\n>   option, which may also change the output.\n>\n> Does this work?\n\nUpdated the patch with the revised wording:\nhttps://lore.kernel.org/git/pull.2113.git.1778686956622.gitgitgadget@gmail.com/T/#t\n\nPlease feel free to pick up, modify, or drop as appropriate.\n"},{"id":"544907","messageId":"20260608105821.GA2049040@cventin.lip.ens-lyon.fr","threadId":"65626","inReplyTo":"CAC2QwmKjr2eiFNPPmERq7n-UjE-SF2vE4eHDanYE-4heWxzQVw@mail.gmail.com","subject":"Re: [BUG] \"git diff --word-diff\" gives a diff while they are only space changes","fromName":"Vincent Lefevre","fromEmail":"vincent@vinc17.net","sentAt":"2026-06-08T10:58:21Z","receivedAt":"2026-06-08T11:04:37Z","isPatch":false,"body":"On 2026-05-28 12:25:01 -0700, Michael Montalbo wrote:\n> > Thanks for the ideas, Chris. Here is my attempt at synthesizing Chris'\n> > suggestions and Junio's feedback:\n> >\n> >   The `--word-diff` option operates by taking the same line-by-line\n> >   diff that is produced without the option and computing\n> >   word-by-word changes within each hunk.  This may produce a\n> >   larger diff than a dedicated word-diff tool would.  If Git\n> >   acquires a different implementation in the future, the output\n> >   may change.  Note that this is similar to the `--diff-algorithm`\n> >   option, which may also change the output.\n> >\n> > Does this work?\n> \n> Updated the patch with the revised wording:\n> https://lore.kernel.org/git/pull.2113.git.1778686956622.gitgitgadget@gmail.com/T/#t\n> \n> Please feel free to pick up, modify, or drop as appropriate.\n\nJust to say that this new text is fine for me.\n\n-- \nVincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>\n100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>\nWork: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)\n"}]}