{"thread":{"id":"50710","subject":"Deprecating git diff ..; dealing with other ranges","startedAt":"2019-03-11T09:37:58Z","lastAt":"2019-03-18T18:52:11Z","messageCount":14,"participants":["Denton Liu","Johannes Schindelin","Elijah Newren","Junio C Hamano","Andreas Schwab","Ævar Arnfjörð Bjarmason","Duy Nguyen","Johannes Sixt","Michal Suchánek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"371136","messageId":"20190311093751.GA31092@archbookpro.localdomain","threadId":"50710","inReplyTo":null,"subject":"Deprecating git diff ..; dealing with other ranges","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-11T09:37:51Z","receivedAt":"2019-03-11T09:37:58Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hello all,\n\nI was in the process of deprecating `git diff ..` as\ndiscussed here[1]. However, I ran into a weird case that I'm not sure\nhow to deal with.\n\nIn t3430-rebase-merges.sh:382, we have the following test case which\ninvokes git diff:\n\n\ttest_expect_success 'with --autosquash and --exec' '\n\t\tgit checkout -b with-exec H &&\n\t\techo Booh >B.t &&\n\t\ttest_tick &&\n\t\tgit commit --fixup B B.t &&\n\t\twrite_script show.sh <<-\\EOF &&\n\t\tsubject=\"$(git show -s --format=%s HEAD)\"\n=>\t\tcontent=\"$(git diff HEAD^! | tail -n 1)\"\n\t\techo \"$subject: $content\"\n\t\tEOF\n\t\ttest_tick &&\n\t\tgit rebase -ir --autosquash --exec ./show.sh A >actual &&\n\t\tgrep \"B: +Booh\" actual &&\n\t\tgrep \"E: +Booh\" actual &&\n\t\tgrep \"G: +G\" actual\n\t'\n\nIt gets caught in my attempt to only deprecate ..'s. Technically, it's\nundocumented behaviour and it only happens to work because git-diff\naccept ranges but it doesn't operate in an intuitive way.\n\nI was just wondering what we should do about this case? Should we\ndeprecate all invocations of `git diff ` except for the special\ncase of `git diff ...`, or should we _only_ deprecate\n`git diff ..` and allow all other forms of ranges, even\nthough it was undocumented behaviour?\n\nThanks,\n\nDenton\n\n[1]: https://public-inbox.org/git/xmqqmumy6mxe.fsf@gitster-ct.c.googlers.com/\n"},{"id":"371147","messageId":"nycvar.QRO.7.76.6.1903111412280.41@tvgsbejvaqbjf.bet","threadId":"50710","inReplyTo":"20190311093751.GA31092@archbookpro.localdomain","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-11T13:19:21Z","receivedAt":"2019-03-11T13:21:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Denton,\n\nOn Mon, 11 Mar 2019, Denton Liu wrote:\n\n> I was in the process of deprecating `git diff ..` as\n> discussed here[1]. However, I ran into a weird case that I'm not sure\n> how to deal with.\n> \n> In t3430-rebase-merges.sh:382, we have the following test case which\n> invokes git diff:\n> \n> \ttest_expect_success 'with --autosquash and --exec' '\n> \t\tgit checkout -b with-exec H &&\n> \t\techo Booh >B.t &&\n> \t\ttest_tick &&\n> \t\tgit commit --fixup B B.t &&\n> \t\twrite_script show.sh <<-\\EOF &&\n> \t\tsubject=\"$(git show -s --format=%s HEAD)\"\n> =>\t\tcontent=\"$(git diff HEAD^! | tail -n 1)\"\n> \t\techo \"$subject: $content\"\n> \t\tEOF\n> \t\ttest_tick &&\n> \t\tgit rebase -ir --autosquash --exec ./show.sh A >actual &&\n> \t\tgrep \"B: +Booh\" actual &&\n> \t\tgrep \"E: +Booh\" actual &&\n> \t\tgrep \"G: +G\" actual\n> \t'\n> \n> It gets caught in my attempt to only deprecate ..'s. Technically, it's\n> undocumented behaviour and it only happens to work because git-diff\n> accept ranges but it doesn't operate in an intuitive way.\n\nI beg to differ. `git diff ^!` does exactly what I want: it shows\nthe diff between the commit's first parent and the commit.\n\nAnd I would not necessarily call this a \"range\". It is a short-hand. Can't\nyou allow short-hands in `git diff`, and disallow only ranges that have an\nexplicit `..` in them? You might need to record that somewhere, but I\nthink that should be easy enough.\n\nCiao,\nJohannes\n\n> \n> I was just wondering what we should do about this case? Should we\n> deprecate all invocations of `git diff ` except for the special\n> case of `git diff ...`, or should we _only_ deprecate\n> `git diff ..` and allow all other forms of ranges, even\n> though it was undocumented behaviour?\n> \n> Thanks,\n> \n> Denton\n> \n> [1]: https://public-inbox.org/git/xmqqmumy6mxe.fsf@gitster-ct.c.googlers.com/\n> \n"},{"id":"371154","messageId":"CABPp-BEfNa88bc6rb7xWxJNOiGdTpc-9+=_1od52kDxOfK3XEA@mail.gmail.com","threadId":"50710","inReplyTo":"20190311093751.GA31092@archbookpro.localdomain","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-11T15:34:34Z","receivedAt":"2019-03-11T15:34:49Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Mon, Mar 11, 2019 at 2:37 AM Denton Liu wrote:\n>\n> Hello all,\n>\n> I was in the process of deprecating `git diff ..` as\n> discussed here[1]. However, I ran into a weird case that I'm not sure\n> how to deal with.\n>\n> In t3430-rebase-merges.sh:382, we have the following test case which\n> invokes git diff:\n>\n> test_expect_success 'with --autosquash and --exec' '\n> git checkout -b with-exec H &&\n> echo Booh >B.t &&\n> test_tick &&\n> git commit --fixup B B.t &&\n> write_script show.sh <<-\\EOF &&\n> subject=\"$(git show -s --format=%s HEAD)\"\n> => content=\"$(git diff HEAD^! | tail -n 1)\"\n> echo \"$subject: $content\"\n> EOF\n> test_tick &&\n> git rebase -ir --autosquash --exec ./show.sh A >actual &&\n> grep \"B: +Booh\" actual &&\n> grep \"E: +Booh\" actual &&\n> grep \"G: +G\" actual\n> '\n>\n> It gets caught in my attempt to only deprecate ..'s. Technically, it's\n> undocumented behaviour and it only happens to work because git-diff\n> accept ranges but it doesn't operate in an intuitive way.\n>\n> I was just wondering what we should do about this case? Should we\n> deprecate all invocations of `git diff ` except for the special\n> case of `git diff ...`, or should we _only_ deprecate\n> `git diff ..` and allow all other forms of ranges, even\n> though it was undocumented behaviour?\n\nThere's a few angles I can think of to view this from:\n\nFirst, commit^! is somewhat of a degenerate \"range\"; it includes only\none commit and for non-merge commits, is equal to both\ncommit~1..commit and commit~1...commit. The fact that those ranges\nare equal means that \"git diff commit~1..commit\" and \"git diff\ncommit~1...commit\" will also give equal results, i.e. that this is not\na case where confusion between '..' and '...' will cause any problems\nfor the user. (Admittedly, I'm ignoring usage of ^! with a merge\ncommit here; I've never seen anyone use it in such a case.)\n\nSecond, ^! is unlikely to cause confusion for users the way '..' vs\n'...' will, because the syntax makes no sense with diff anyway. It's\ntotally magical, and when I came across it being used with diff\ninstead of log, I had to test it out to determine what it did. (I do\nnow find it handy and use it occasionally.) It's fairly difficult to\nexplain to beginners -- I tried once and quickly gave up and used\nlonger but more straightforward alternatives. So, IMO, this is only a\nconvenience syntax for experts, and a syntax that won't be confused\nwith other syntax out there, so there's no need to deprecate it.\n\nThird, we have good reason to deprecate explicit usage of '..' with\ngit diff, but even with those reasons some folks probably aren't\nconvinced it's worth the effort. I want to avoid expanding scope, for\nfear of moving some people from the sidelines of \"not worth the\neffort\" to \"this is a bad idea\". So if there are other range syntax\ncases used in the wild (maybe 'git diff merge_commit^@' ?!?), we\nshould just leave them be and allow them to continue working.\n\n\nHope that helps,\nElijah\n"},{"id":"371224","messageId":"xmqqmum0h88n.fsf@gitster-ct.c.googlers.com","threadId":"50710","inReplyTo":"20190311093751.GA31092@archbookpro.localdomain","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-12T07:17:28Z","receivedAt":"2019-03-12T07:17:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Denton Liu writes:\n\n> I was in the process of deprecating `git diff ..` as\n> discussed here[1].\n>\n> [1]: https://public-inbox.org/git/xmqqmumy6mxe.fsf@gitster-ct.c.googlers.com/\n\nI didn't (and don't) advocate such a deprecation, FWIW, in that\nmessage. I simply do not think it is worth the cost.\n\nI however think it may be worth making sure that our docs do not\nencourage \"diff A..B\" and teach \"diff A B\" when comparing two\nendpoints. That can be done without changing anything in the code.\n\n"},{"id":"371225","messageId":"xmqqef7ch80v.fsf@gitster-ct.c.googlers.com","threadId":"50710","inReplyTo":"20190311093751.GA31092@archbookpro.localdomain","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-12T07:22:08Z","receivedAt":"2019-03-12T07:22:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Denton Liu writes:\n\n> =>\t\tcontent=\"$(git diff HEAD^! | tail -n 1)\"\n> ...\n> It gets caught in my attempt to only deprecate ..'s. Technically, it's\n> undocumented behaviour and it only happens to work because git-diff\n> accept ranges but it doesn't operate in an intuitive way.\n\nIt reuses the same notation as that is used for ranges, but makes\nthe notation mean something entirely different from ranges, because\n\"diff\" is about two endpoints.\n\nAnd \"git diff ^A B\" (or \"git diff B ^A\") works like \"git diff A B\".\nSo does \"git diff A^!\", for a single-parent commit A, work like \"git\ndiff A^ A\".\n"},{"id":"371276","messageId":"87va0orop4.fsf@igel.home","threadId":"50710","inReplyTo":"xmqqmum0h88n.fsf@gitster-ct.c.googlers.com","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2019-03-12T17:24:07Z","receivedAt":"2019-03-12T17:24:19Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Mär 12 2019, Junio C Hamano wrote:\n\n> I however think it may be worth making sure that our docs do not\n> encourage \"diff A..B\" and teach \"diff A B\" when comparing two\n> endpoints. That can be done without changing anything in the code.\n\nThe nice thing about \"diff A..B\" is that you can c&p the output from the\nfetch run without the need to edit it.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"371298","messageId":"87wol3bydp.fsf@evledraar.gmail.com","threadId":"50710","inReplyTo":"87va0orop4.fsf@igel.home","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-03-12T21:01:38Z","receivedAt":"2019-03-12T21:01:43Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Mar 12 2019, Andreas Schwab wrote:\n\n> On Mär 12 2019, Junio C Hamano wrote:\n>\n>> I however think it may be worth making sure that our docs do not\n>> encourage \"diff A..B\" and teach \"diff A B\" when comparing two\n>> endpoints. That can be done without changing anything in the code.\n>\n> The nice thing about \"diff A..B\" is that you can c&p the output from the\n> fetch run without the need to edit it.\n\nNot to shoot down this effort, just to add another similar thing I do\nregularly for ff-branches:\n\n 1. Copy/paste A..B fetch output\n 2. git log A..B\n 3. ^log^diff\n\nI.e. I just need to tell my terminal to re-run the same \"log\" command\nwith \"diff\" instead of \"log\".\n\nOf course as covered in the linked thread it doesn't work for some\n(non-ff) cases, and I'll sometimes end up cursing it and swapping around\n\"..\" for \"...\" with log/diff.\n"},{"id":"371313","messageId":"CACsJy8DaTE3fbLZCbwW6XY4Z_2OjczOZROYiWsMPQrni_ybhZg@mail.gmail.com","threadId":"50710","inReplyTo":"87va0orop4.fsf@igel.home","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-03-13T01:20:34Z","receivedAt":"2019-03-13T01:21:03Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Mar 13, 2019 at 12:26 AM Andreas Schwab wrote:\n>\n> On Mär 12 2019, Junio C Hamano wrote:\n>\n> > I however think it may be worth making sure that our docs do not\n> > encourage \"diff A..B\" and teach \"diff A B\" when comparing two\n> > endpoints. That can be done without changing anything in the code.\n>\n> The nice thing about \"diff A..B\" is that you can c&p the output from the\n> fetch run without the need to edit it.\n\nI do this copy&paste too though I think in this case we could improve\nsomething to not copy&paste in the first place.\n\nA..B from fetch is the same as branch@{1}..branch. If we have some\nshortcut similar to ^! but for reflog, that would be perfect (the\nbranch part does not require much typing with tab completion).\n-- \nDuy\n"},{"id":"371333","messageId":"07998a4f-b5a7-dc27-efdc-d12f99a8306f@kdbg.org","threadId":"50710","inReplyTo":"87wol3bydp.fsf@evledraar.gmail.com","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-03-13T07:01:42Z","receivedAt":"2019-03-13T07:01:48Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 12.03.19 um 22:01 schrieb Ævar Arnfjörð Bjarmason:\n> \n> On Tue, Mar 12 2019, Andreas Schwab wrote:\n> \n>> On Mär 12 2019, Junio C Hamano wrote:\n>>\n>>> I however think it may be worth making sure that our docs do not\n>>> encourage \"diff A..B\" and teach \"diff A B\" when comparing two\n>>> endpoints. That can be done without changing anything in the code.\n>>\n>> The nice thing about \"diff A..B\" is that you can c&p the output from the\n>> fetch run without the need to edit it.\n> \n> Not to shoot down this effort, just to add another similar thing I do\n> regularly for ff-branches:\n> \n> 1. Copy/paste A..B fetch output\n> 2. git log A..B\n> 3. ^log^diff\n> \n> I.e. I just need to tell my terminal to re-run the same \"log\" command\n> with \"diff\" instead of \"log\".\n> \n> Of course as covered in the linked thread it doesn't work for some\n> (non-ff) cases, and I'll sometimes end up cursing it and swapping around\n> \"..\" for \"...\" with log/diff.\n\nStill, your and Andreas's use-case is reason enough *not* to deprecate\ndiff A..B, IMO.\n\nWe wouldn't be able to remove .. wholesale anyway because diff A.. and\ndiff ..B, where the missing endpoints are filled in with HEAD would have\nto live on.\n\n-- Hannes\n"},{"id":"371380","messageId":"87wol28wza.fsf@igel.home","threadId":"50710","inReplyTo":"CACsJy8DaTE3fbLZCbwW6XY4Z_2OjczOZROYiWsMPQrni_ybhZg@mail.gmail.com","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2019-03-13T18:12:25Z","receivedAt":"2019-03-13T18:12:31Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Mär 13 2019, Duy Nguyen wrote:\n\n> A..B from fetch is the same as branch@{1}..branch. If we have some\n> shortcut similar to ^! but for reflog, that would be perfect (the\n> branch part does not require much typing with tab completion).\n\nTab completion is much slower than c&p, especially if the completion is\nambigous.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"371827","messageId":"CABPp-BHMi=RTWAVjuORdTWY3ijp4EKhy2QAH0=WrviCiotJtyw@mail.gmail.com","threadId":"50710","inReplyTo":"87wol3bydp.fsf@evledraar.gmail.com","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-18T17:07:08Z","receivedAt":"2019-03-18T17:07:24Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason\n wrote:\n> On Tue, Mar 12 2019, Andreas Schwab wrote:\n> > On Mär 12 2019, Junio C Hamano wrote:\n> >\n> >> I however think it may be worth making sure that our docs do not\n> >> encourage \"diff A..B\" and teach \"diff A B\" when comparing two\n> >> endpoints. That can be done without changing anything in the code.\n> >\n> > The nice thing about \"diff A..B\" is that you can c&p the output from the\n> > fetch run without the need to edit it.\n>\n> Not to shoot down this effort, just to add another similar thing I do\n> regularly for ff-branches:\n>\n> 1. Copy/paste A..B fetch output\n> 2. git log A..B\n> 3. ^log^diff\n>\n> I.e. I just need to tell my terminal to re-run the same \"log\" command\n> with \"diff\" instead of \"log\".\n>\n> Of course as covered in the linked thread it doesn't work for some\n> (non-ff) cases, and I'll sometimes end up cursing it and swapping around\n> \"..\" for \"...\" with log/diff.\n\nDoesn't this somewhat imply that although you use diff A..B here for\nconvenience, that it's actually wrong since what you really want is\nA...B? Or said another way, the end goal of deprecating \"diff \"A..B\"\nthen later reinstating \"diff A..B\" to mean the same thing as \"diff\nA...B\" would actually be better even for your usecase?\n\nOf course, switching to the removal period may just be too painful for\ntoo many folks since there are obviously people that use it, but I\njust want to see if I'm understanding correctly here.\n"},{"id":"371828","messageId":"20190318181144.02dea38f@kitsune.suse.cz","threadId":"50710","inReplyTo":"CABPp-BHMi=RTWAVjuORdTWY3ijp4EKhy2QAH0=WrviCiotJtyw@mail.gmail.com","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2019-03-18T17:11:44Z","receivedAt":"2019-03-18T17:11:48Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Mon, 18 Mar 2019 10:07:08 -0700\nElijah Newren wrote:\n\n> On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason\n> wrote:\n> > On Tue, Mar 12 2019, Andreas Schwab wrote: \n> > > On Mär 12 2019, Junio C Hamano wrote:\n> > > \n> > >> I however think it may be worth making sure that our docs do not\n> > >> encourage \"diff A..B\" and teach \"diff A B\" when comparing two\n> > >> endpoints. That can be done without changing anything in the code. \n> > >\n> > > The nice thing about \"diff A..B\" is that you can c&p the output from the\n> > > fetch run without the need to edit it. \n> >\n> > Not to shoot down this effort, just to add another similar thing I do\n> > regularly for ff-branches:\n> >\n> > 1. Copy/paste A..B fetch output\n> > 2. git log A..B\n> > 3. ^log^diff\n> >\n> > I.e. I just need to tell my terminal to re-run the same \"log\" command\n> > with \"diff\" instead of \"log\".\n> >\n> > Of course as covered in the linked thread it doesn't work for some\n> > (non-ff) cases, and I'll sometimes end up cursing it and swapping around\n> > \"..\" for \"...\" with log/diff. \n> \n> Doesn't this somewhat imply that although you use diff A..B here for\n> convenience, that it's actually wrong since what you really want is\n> A...B? Or said another way, the end goal of deprecating \"diff \"A..B\"\n> then later reinstating \"diff A..B\" to mean the same thing as \"diff\n> A...B\" would actually be better even for your usecase?\n\nI usually mean diff A..B in this case.\n\nThanks\n\nMichal\n"},{"id":"371832","messageId":"87o968dpy2.fsf@evledraar.gmail.com","threadId":"50710","inReplyTo":"CABPp-BHMi=RTWAVjuORdTWY3ijp4EKhy2QAH0=WrviCiotJtyw@mail.gmail.com","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-03-18T17:59:01Z","receivedAt":"2019-03-18T17:59:07Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Mar 18 2019, Elijah Newren wrote:\n\n> On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason\n> wrote:\n>> On Tue, Mar 12 2019, Andreas Schwab wrote:\n>> > On Mär 12 2019, Junio C Hamano wrote:\n>> >\n>> >> I however think it may be worth making sure that our docs do not\n>> >> encourage \"diff A..B\" and teach \"diff A B\" when comparing two\n>> >> endpoints. That can be done without changing anything in the code.\n>> >\n>> > The nice thing about \"diff A..B\" is that you can c&p the output from the\n>> > fetch run without the need to edit it.\n>>\n>> Not to shoot down this effort, just to add another similar thing I do\n>> regularly for ff-branches:\n>>\n>> 1. Copy/paste A..B fetch output\n>> 2. git log A..B\n>> 3. ^log^diff\n>>\n>> I.e. I just need to tell my terminal to re-run the same \"log\" command\n>> with \"diff\" instead of \"log\".\n>>\n>> Of course as covered in the linked thread it doesn't work for some\n>> (non-ff) cases, and I'll sometimes end up cursing it and swapping around\n>> \"..\" for \"...\" with log/diff.\n>\n> Doesn't this somewhat imply that although you use diff A..B here for\n> convenience, that it's actually wrong since what you really want is\n> A...B?\n\nYeah \"...\" would be more correct, but usually when I do this it's for\nthings where the LHS hasn't diverged.\n\n> Or said another way, the end goal of deprecating \"diff \"A..B\"\n> then later reinstating \"diff A..B\" to mean the same thing as \"diff\n> A...B\" would actually be better even for your usecase?\n\nYeah, it would be. Sometimes I need to go back and tweak it to be \"...\"\ninstead of \"..\" now. When the two have different behavior I usually want\nthe former.\n\n> Of course, switching to the removal period may just be too painful for\n> too many folks since there are obviously people that use it, but I\n> just want to see if I'm understanding correctly here.\n\nI think we'd ideally migrate, but the conversion might be too\npainful. Junio doesn't seem excited in\n\n\nI'm not claiming that this ^log^diff use-case is common or anything,\njust noting a use-case I do use occasionally and mostly works now.\n"},{"id":"371835","messageId":"CABPp-BHcTTXZDbP00e-5O3ESV420HPjYUO0sQMvYmMTd1No1vg@mail.gmail.com","threadId":"50710","inReplyTo":"20190318181144.02dea38f@kitsune.suse.cz","subject":"Re: Deprecating git diff ..; dealing with other ranges","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-18T18:51:56Z","receivedAt":"2019-03-18T18:52:11Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Mar 18, 2019 at 10:11 AM Michal Suchánek wrote:\n>\n> On Mon, 18 Mar 2019 10:07:08 -0700\n> Elijah Newren wrote:\n>\n> > On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason\n> > wrote:\n> > > On Tue, Mar 12 2019, Andreas Schwab wrote:\n> > > > On Mär 12 2019, Junio C Hamano wrote:\n> > > >\n> > > >> I however think it may be worth making sure that our docs do not\n> > > >> encourage \"diff A..B\" and teach \"diff A B\" when comparing two\n> > > >> endpoints. That can be done without changing anything in the code.\n> > > >\n> > > > The nice thing about \"diff A..B\" is that you can c&p the output from the\n> > > > fetch run without the need to edit it.\n> > >\n> > > Not to shoot down this effort, just to add another similar thing I do\n> > > regularly for ff-branches:\n> > >\n> > > 1. Copy/paste A..B fetch output\n> > > 2. git log A..B\n> > > 3. ^log^diff\n> > >\n> > > I.e. I just need to tell my terminal to re-run the same \"log\" command\n> > > with \"diff\" instead of \"log\".\n> > >\n> > > Of course as covered in the linked thread it doesn't work for some\n> > > (non-ff) cases, and I'll sometimes end up cursing it and swapping around\n> > > \"..\" for \"...\" with log/diff.\n> >\n> > Doesn't this somewhat imply that although you use diff A..B here for\n> > convenience, that it's actually wrong since what you really want is\n> > A...B? Or said another way, the end goal of deprecating \"diff \"A..B\"\n> > then later reinstating \"diff A..B\" to mean the same thing as \"diff\n> > A...B\" would actually be better even for your usecase?\n>\n> I usually mean diff A..B in this case.\n\nThanks for the feedback; somewhat odd that you and Ævar have the same\nusecase but want the opposite meaning, but good to know nonetheless.\n"}]}