{"thread":{"id":"60634","subject":"Is --minimal ever not the right thing?","startedAt":"2023-12-19T16:10:44Z","lastAt":"2023-12-19T18:18:19Z","messageCount":4,"participants":["Tao Klerks","Mike Castle","Elijah Newren","Konstantin Tokarev"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"485816","messageId":"CAPMMpohbQK+3o46iiY+0o=vS+UC_HBB=CxsNT_hAb5dDz+514Q@mail.gmail.com","threadId":"60634","inReplyTo":null,"subject":"Is --minimal ever not the right thing?","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-12-19T16:10:29Z","receivedAt":"2023-12-19T16:10:44Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"Hi folks,\n\nA user today showed me a situation where `git diff` (and `git blame`)\nseemed to be doing the wrong thing: where two big blocks of text were\nremoved from a file, leaving 4 lines untouched in the middle, the\ndefault diff was noting all three regions as lines removed, with those\n4 \"untouched\" lines as *added* in the same place.\n\nWe compared to another diffing tool, p4merge, and that was showing\n\"the right thing\" - two deleted regions with untouched lines in the\nmiddle.\n\nWe realized that `--minimal` does \"the right thing\" in git, and you\ncan set up `diff.algorithm` config to use it by default in `git diff`\n(although `git blame` doesn't currently/yet support it... a small\nenhancement opportunity there :) ), but that raises two questions:\n\n1. Is there any practical reason for any user *not* to set\n`diff.algorithm` to `minimal`? Has anyone ever done an analysis of the\nperformance cost (or \"diff readability cost\", if that is a thing) of\n\"minimal\" vs \"default\"?\n\n2. If \"minimal\" is just better, and its higher computational cost is\neffectively trivial, then why wouldn't we change the default?\n\nI suspect this comes down to situations where git does big diffs\nbehind the scenes...? But I don't know offhand.\n\nAny feedback would be most appreciated!\n\nThanks,\nTao\n"},{"id":"485822","messageId":"CA+t9iMyrLAekwQHNky4w9nWD6WwxidxwfSmbqCpSRnkJgoQ0LA@mail.gmail.com","threadId":"60634","inReplyTo":"CAPMMpohbQK+3o46iiY+0o=vS+UC_HBB=CxsNT_hAb5dDz+514Q@mail.gmail.com","subject":"Re: Is --minimal ever not the right thing?","fromName":"Mike Castle","fromEmail":"dalgoda@gmail.com","sentAt":"2023-12-19T17:25:18Z","receivedAt":"2023-12-19T17:25:31Z","isPatch":false,"sender":{"key":"dalgoda@gmail.com","avatar":null},"body":"I believe that the diff algorithms available are the same one's in GNU\ndiff.  From https://www.gnu.org/software/diffutils/manual/html_node/diff-Performance.html:\n\"\"\"\nThe way that GNU diff determines which lines have changed always comes\nup with a near-minimal set of differences. Usually it is good enough\nfor practical purposes. If the diff output is large, you might want\ndiff to use a modified algorithm that sometimes produces a smaller set\nof differences. The --minimal (-d) option does this; however, it can\nalso cause diff to run more slowly than usual, so it is not the\ndefault behavior.\n\"\"\"\n\nSince it has been that way decades before git even existed, I suspect\n(but do not know) that, yes, analysis has been performed, and it makes\nsense to keep the current default.\n\nThen again, in the decades sense, the entire stack from hardware to\ncompilers has improved, and maybe it does deserve a revisit.  You\ncould check whatever email archives is used for diffutils and see if\nthere has been any discussion on it recently (say, last 5 years?).\n\nAs you pointed out, you can set it yourself and see what happens over time.\n\nCheers,\nmrc\n"},{"id":"485825","messageId":"CABPp-BEmgOAj17DozyXNaf-9CawDic4uTpMbckef3+zHf7URqQ@mail.gmail.com","threadId":"60634","inReplyTo":"CA+t9iMyrLAekwQHNky4w9nWD6WwxidxwfSmbqCpSRnkJgoQ0LA@mail.gmail.com","subject":"Re: Is --minimal ever not the right thing?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-12-19T17:55:34Z","receivedAt":"2023-12-19T17:55:48Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"To add to what Mike said...\n\nOn Tue, Dec 19, 2023 at 9:25 AM Mike Castle <dalgoda@gmail.com> wrote:\n>\n> I believe that the diff algorithms available are the same one's in GNU\n> diff.  From https://www.gnu.org/software/diffutils/manual/html_node/diff-Performance.html:\n> \"\"\"\n> The way that GNU diff determines which lines have changed always comes\n> up with a near-minimal set of differences. Usually it is good enough\n> for practical purposes. If the diff output is large, you might want\n> diff to use a modified algorithm that sometimes produces a smaller set\n> of differences. The --minimal (-d) option does this; however, it can\n> also cause diff to run more slowly than usual, so it is not the\n> default behavior.\n> \"\"\"\n>\n> Since it has been that way decades before git even existed, I suspect\n> (but do not know) that, yes, analysis has been performed, and it makes\n> sense to keep the current default.\n>\n> Then again, in the decades sense, the entire stack from hardware to\n> compilers has improved, and maybe it does deserve a revisit.  You\n> could check whatever email archives is used for diffutils and see if\n> there has been any discussion on it recently (say, last 5 years?).\n>\n> As you pointed out, you can set it yourself and see what happens over time.\n\nThere have been various discussions of diff performance, quality of\nresults, what the default should be, etc.  Including within the last\nyear.\n\nminimal is guaranteed to produce a minimal diff, i.e. fewest total\nsubtractions and additions.  That is sometimes \"best\" quality, but\ndefinitely not always.  On the performance axis, in special cases\nminimal can be nearly as fast as myers and the other diff algorithms,\nbut only in special cases.\n\nI think patience or histogram would make better defaults, at least\nwith some tweaks.  I had some patches to improve some worst case\nperformance and quality results coming from histogram that I was\nworking on in early 2023, but those got put on the backburner when\n$DAYJOB pulled support for my Git work.  And I'm not aware of anyone\nelse currently working in the area.\n\nHope that helps,\nElijah\n"},{"id":"485826","messageId":"20231219210949.747ddd50@RedEyes","threadId":"60634","inReplyTo":"CABPp-BEmgOAj17DozyXNaf-9CawDic4uTpMbckef3+zHf7URqQ@mail.gmail.com","subject":"Re: Is --minimal ever not the right thing?","fromName":"Konstantin Tokarev","fromEmail":"annulen@yandex.ru","sentAt":"2023-12-19T18:09:49Z","receivedAt":"2023-12-19T18:18:19Z","isPatch":false,"sender":{"key":"annulen@yandex.ru","avatar":null},"body":"On Tue, 19 Dec 2023 09:55:34 -0800\nElijah Newren <newren@gmail.com> wrote:\n\n> minimal is guaranteed to produce a minimal diff, i.e. fewest total\n> subtractions and additions.  That is sometimes \"best\" quality, but\n> definitely not always. \n\nI second this. Recently I had a case when I had to use --anchored\noption of git diff to produce more informative diff instead of minimal\none.\n"}]}