{"thread":{"id":"64328","subject":"[PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","startedAt":"2025-10-15T22:07:36Z","lastAt":"2025-10-16T20:42:17Z","messageCount":14,"participants":["Martin von Zweigbergk via GitGitGadget","Junio C Hamano","brian m. carlson","Martin von Zweigbergk","Justin Tobler","Kristoffer Haugsbakk","D. Ben Knoble"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"528866","messageId":"pull.1989.git.1760566054455.gitgitgadget@gmail.com","threadId":"64328","inReplyTo":null,"subject":"[PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Martin von Zweigbergk via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2025-10-15T22:07:34Z","receivedAt":"2025-10-15T22:07:36Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"From: Martin von Zweigbergk \n\nThe `git diff X..Y` syntax is quite misleading because it looks like\nit shows the diff of the commits in the X..Y range but it actually\nshows the diff from X to Y. IMO, if that syntax is supported, it\nshould show a diff from the merge base of X and Y to Y. I hope Git 3.0\nis a good time to remove support for the current syntax and\nsemantics. Then we can perhaps add the syntax back later with less\nsurprising semantics.\n\nSigned-off-by: Martin von Zweigbergk \n---\n BreakingChanges: say that git diff X..Y syntax will be removed in 3.0\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1989%2Fmartinvonz%2Fmz%2Fwtmnpolouvvz-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1989/martinvonz/mz/wtmnpolouvvz-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1989\n\n Documentation/BreakingChanges.adoc | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc\nindex 90b53abcea..93fb968840 100644\n--- a/Documentation/BreakingChanges.adoc\n+++ b/Documentation/BreakingChanges.adoc\n@@ -114,6 +114,10 @@ applications and forges.\n +\n There is no plan to deprecate the \"sha1\" object format at this point in time.\n +\n+Support for \"git diff X..Y\" syntax will be removed. Use \"git diff X Y\" instead.\n+This will open up the syntax for a more consistent interpretation of\n+\"git diff $(git merge-base X Y) Y\".\n++\n Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>,\n <20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,\n .\n\nbase-commit: 143f58ef7535f8f8a80d810768a18bdf3807de26\n-- \ngitgitgadget\n"},{"id":"528869","messageId":"xmqq4irzu7st.fsf@gitster.g","threadId":"64328","inReplyTo":"pull.1989.git.1760566054455.gitgitgadget@gmail.com","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-15T22:19:46Z","receivedAt":"2025-10-15T22:19:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin von Zweigbergk via GitGitGadget\" \nwrites:\n\n> From: Martin von Zweigbergk \n>\n> The `git diff X..Y` syntax is quite misleading because it looks like\n> it shows the diff of the commits in the X..Y range but it actually\n> shows the diff from X to Y. IMO, if that syntax is supported, it\n> should show a diff from the merge base of X and Y to Y. I hope Git 3.0\n> is a good time to remove support for the current syntax and\n> semantics. Then we can perhaps add the syntax back later with less\n> surprising semantics.\n>\n> Signed-off-by: Martin von Zweigbergk \n> ---\n> BreakingChanges: say that git diff X..Y syntax will be removed in 3.0\n\nI like it in prinicple and I do wish that we didn't do the lazy\nthing when we did the command line parser for \"git diff\" (we had\nrevision range parser, so we just reused it instead of doing our own\nfor \"git diff\"). But real life may bite us back.\n\nIn any case, a declaration that does not come with code changes that\nare protected by WITH_BREAKING_CHANGES CPP macro is a patch that is\nnot quite ready to be applied.\n\n\n\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1989%2Fmartinvonz%2Fmz%2Fwtmnpolouvvz-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1989/martinvonz/mz/wtmnpolouvvz-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/1989\n>\n> Documentation/BreakingChanges.adoc | 4 ++++\n> 1 file changed, 4 insertions(+)\n>\n> diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc\n> index 90b53abcea..93fb968840 100644\n> --- a/Documentation/BreakingChanges.adoc\n> +++ b/Documentation/BreakingChanges.adoc\n> @@ -114,6 +114,10 @@ applications and forges.\n> +\n> There is no plan to deprecate the \"sha1\" object format at this point in time.\n> +\n> +Support for \"git diff X..Y\" syntax will be removed. Use \"git diff X Y\" instead.\n> +This will open up the syntax for a more consistent interpretation of\n> +\"git diff $(git merge-base X Y) Y\".\n> ++\n> Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>,\n> <20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,\n> .\n>\n> base-commit: 143f58ef7535f8f8a80d810768a18bdf3807de26\n"},{"id":"528894","messageId":"aPAgBPLH4QYa0ceP@fruit.crustytoothpaste.net","threadId":"64328","inReplyTo":"pull.1989.git.1760566054455.gitgitgadget@gmail.com","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-15T22:28:20Z","receivedAt":"2025-10-15T22:28:28Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-15 at 22:07:34, Martin von Zweigbergk via GitGitGadget wrote:\n> From: Martin von Zweigbergk \n> \n> The `git diff X..Y` syntax is quite misleading because it looks like\n> it shows the diff of the commits in the X..Y range but it actually\n> shows the diff from X to Y. IMO, if that syntax is supported, it\n> should show a diff from the merge base of X and Y to Y. I hope Git 3.0\n> is a good time to remove support for the current syntax and\n> semantics. Then we can perhaps add the syntax back later with less\n> surprising semantics.\n> \n> Signed-off-by: Martin von Zweigbergk \n> ---\n> BreakingChanges: say that git diff X..Y syntax will be removed in 3.0\n> \n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1989%2Fmartinvonz%2Fmz%2Fwtmnpolouvvz-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1989/martinvonz/mz/wtmnpolouvvz-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/1989\n> \n> Documentation/BreakingChanges.adoc | 4 ++++\n> 1 file changed, 4 insertions(+)\n> \n> diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc\n> index 90b53abcea..93fb968840 100644\n> --- a/Documentation/BreakingChanges.adoc\n> +++ b/Documentation/BreakingChanges.adoc\n> @@ -114,6 +114,10 @@ applications and forges.\n> +\n> There is no plan to deprecate the \"sha1\" object format at this point in time.\n> +\n> +Support for \"git diff X..Y\" syntax will be removed. Use \"git diff X Y\" instead.\n> +This will open up the syntax for a more consistent interpretation of\n> +\"git diff $(git merge-base X Y) Y\".\n\nI feel like this is going to break a whole lot of existing scripts and\nprobably more than a few forges as well. It seems especially bad that\nwe would add it back in the future with a completely different meaning,\nsince we'll have some people that use 10-year LTS distros that go from,\nsay, Git 2.51 to Git 3.xx, where the latter reintroduces the syntax with\ndifferent semantics.\n\nWe've never really changed the meaning of things like revisions or\nrevision-adjacent code in the past and I think those kinds of things\nwe're pretty much stuck with forever. With that in mind, I don't think\nthis is a good idea.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"528922","messageId":"CAESOdVAHt8nUQRE64RXwS4FiO1=Qy8EPamDwaPqUrHvx7bKCEQ@mail.gmail.com","threadId":"64328","inReplyTo":"xmqq4irzu7st.fsf@gitster.g","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@google.com","sentAt":"2025-10-15T23:06:09Z","receivedAt":"2025-10-15T23:06:21Z","isPatch":true,"sender":{"key":"martinvonz@google.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Wed, 15 Oct 2025 at 15:19, Junio C Hamano wrote:\n>\n> \"Martin von Zweigbergk via GitGitGadget\" \n> writes:\n>\n> > From: Martin von Zweigbergk \n> >\n> > The `git diff X..Y` syntax is quite misleading because it looks like\n> > it shows the diff of the commits in the X..Y range but it actually\n> > shows the diff from X to Y. IMO, if that syntax is supported, it\n> > should show a diff from the merge base of X and Y to Y. I hope Git 3.0\n> > is a good time to remove support for the current syntax and\n> > semantics. Then we can perhaps add the syntax back later with less\n> > surprising semantics.\n> >\n> > Signed-off-by: Martin von Zweigbergk \n> > ---\n> > BreakingChanges: say that git diff X..Y syntax will be removed in 3.0\n>\n> I like it in prinicple and I do wish that we didn't do the lazy\n> thing when we did the command line parser for \"git diff\" (we had\n> revision range parser, so we just reused it instead of doing our own\n> for \"git diff\"). But real life may bite us back.\n\nAh, so that's where it came from. Thanks for explaining. Speaking of\nrevision range parsers, teaching Git something like Mercurial's or\njj's \"revsets\" languages is one reason I would like to get rid of the\n`git diff X..Y` syntax here. I haven't done a comprehensive analysis\nbut this is the only place I've noticed where we would need a breaking\nchange if we ever wanted to teach Git revsets. (I'm not volunteering\nmy time to work on such a project. I just think it would be nice if\nsomeone did :) )\n\n>\n> In any case, a declaration that does not come with code changes that\n> are protected by WITH_BREAKING_CHANGES CPP macro is a patch that is\n> not quite ready to be applied.\n\nYeah, this was meant as a discussion starter. I assumed I had missed a\nfew things as I'm not very familiar with how things are done here. I'm\nhappy to add that WITH_BREAKING_CHANGES macro if there's a V2.\n"},{"id":"528926","messageId":"i5lgq7cunzqn2k3puuudzb53efqz6cxev64l6ukwy2kf24dab3@ndymfd2ocit3","threadId":"64328","inReplyTo":"pull.1989.git.1760566054455.gitgitgadget@gmail.com","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2025-10-16T01:28:36Z","receivedAt":"2025-10-16T01:28:38Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 25/10/15 10:07PM, Martin von Zweigbergk via GitGitGadget wrote:\n> From: Martin von Zweigbergk \n> \n> The `git diff X..Y` syntax is quite misleading because it looks like\n> it shows the diff of the commits in the X..Y range but it actually\n> shows the diff from X to Y. \n\nPersonally, I would like to see both the double-dot and triple-dot\nnotations removed from the diff commands because they are often confused\nwith the revision range notations. In my opinion, the double-dot\nnotation doesn't even have much value as it can be replaced with:\n\n A..B => A B\n A.. => A @\n ..B => @ B\n\nThese alternatives are just as concise. \n\n> IMO, if that syntax is supported, it\n> should show a diff from the merge base of X and Y to Y. I hope Git 3.0\n> is a good time to remove support for the current syntax and\n> semantics. Then we can perhaps add the syntax back later with less\n> surprising semantics.\n\nWith the existing triple-dot notation, `git diff A...B` is equivalent to\n`git diff $(git merge-base A B) B`. I think this is what you are\nsuggesting about that the double-dot notation should do. As mentioned\nearlier, I think both these notations are too easily confused with\nrevision range notations so I think we should avoid using the dot syntax\nfor such a shortcut altogether.\n\nThe triple-dot notation is a somewhat convienient shortcut though. If we\nwanted to remove it, we would maybe want to replace it some other\nfunctionally equivalent shortcut.\n\nAll this being said, I've sure there are folks in the wild using these\nnotations in scripts and changing would cause disruption. Maybe the Git\n3.0 release would indeed be a good time to remove them though.\n\n-Justin\n"},{"id":"528955","messageId":"xmqqh5vz7ygc.fsf@gitster.g","threadId":"64328","inReplyTo":"aPAgBPLH4QYa0ceP@fruit.crustytoothpaste.net","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-16T13:44:51Z","receivedAt":"2025-10-16T13:44:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n>> +Support for \"git diff X..Y\" syntax will be removed. Use \"git diff X Y\" instead.\n>> +This will open up the syntax for a more consistent interpretation of\n>> +\"git diff $(git merge-base X Y) Y\".\n>\n> I feel like this is going to break a whole lot of existing scripts and\n> probably more than a few forges as well. It seems especially bad that\n> we would add it back in the future with a completely different meaning,\n> since we'll have some people that use 10-year LTS distros that go from,\n> say, Git 2.51 to Git 3.xx, where the latter reintroduces the syntax with\n> different semantics.\n>\n> We've never really changed the meaning of things like revisions or\n> revision-adjacent code in the past and I think those kinds of things\n> we're pretty much stuck with forever. With that in mind, I don't think\n> this is a good idea.\n\nI do not think X..Y (or X...Y), if accepted by commands, would never\nchange their meanings in the middle of the commands' lives.\nTeaching \"git diff\" to complain and barf on X..Y is a possibility,\nbut to do the same for X...Y, we would need to come up with an\nalternative syntax first.\n\nThe same for \"git checkout master...\" that detaches HEAD at the\nfork point of the current topic (so that I can \"git am\" in a new\niteration of patches on top). As the syntax \"git diff master...\"\nis symmetric with it, if one were to change, both should change to\nthe same.\n\nThanks.\n\n\n"},{"id":"528970","messageId":"CAESOdVDbVDwmYOFRAAC07GXaJ871FiPWTx58YMLta7vAWDjgfw@mail.gmail.com","threadId":"64328","inReplyTo":"i5lgq7cunzqn2k3puuudzb53efqz6cxev64l6ukwy2kf24dab3@ndymfd2ocit3","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@google.com","sentAt":"2025-10-16T16:34:42Z","receivedAt":"2025-10-16T16:34:54Z","isPatch":true,"sender":{"key":"martinvonz@google.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Wed, 15 Oct 2025 at 18:28, Justin Tobler wrote:\n>\n> On 25/10/15 10:07PM, Martin von Zweigbergk via GitGitGadget wrote:\n> > From: Martin von Zweigbergk \n> >\n> > The `git diff X..Y` syntax is quite misleading because it looks like\n> > it shows the diff of the commits in the X..Y range but it actually\n> > shows the diff from X to Y.\n>\n> Personally, I would like to see both the double-dot and triple-dot\n> notations removed from the diff commands because they are often confused\n> with the revision range notations.\n\nOh, I agree. I had forgotten that the triple-dot notation is also accepted.\n\n> In my opinion, the double-dot\n> notation doesn't even have much value as it can be replaced with:\n>\n> A..B => A B\n> A.. => A @\n> ..B => @ B\n>\n> These alternatives are just as concise.\n>\n> > IMO, if that syntax is supported, it\n> > should show a diff from the merge base of X and Y to Y. I hope Git 3.0\n> > is a good time to remove support for the current syntax and\n> > semantics. Then we can perhaps add the syntax back later with less\n> > surprising semantics.\n>\n> With the existing triple-dot notation, `git diff A...B` is equivalent to\n> `git diff $(git merge-base A B) B`. I think this is what you are\n> suggesting about that the double-dot notation should do. As mentioned\n> earlier, I think both these notations are too easily confused with\n> revision range notations so I think we should avoid using the dot syntax\n> for such a shortcut altogether.\n\nFWIW, `jj diff` can diff between two commits with `jj diff --from A\n--to B`. It can also show the changes in commit A with `jj diff -r A`.\nYou can also show the combined diffs in a range with `jj diff -r A..B`\n(i.e. `jj diff -r A` is a special case of that). I think that's\nconsistent with the range notation because it's the same set of\ncommits that are considered. But both `git diff A..B` and `git diff\nA...B` take range expressions and show diffs that don't correspond to\nthose ranges. So I guess I'm saying that I'm not fundamentally opposed\nto having a way of showing the combined diff in a range, as long as\nit's consistent.\n\n>\n> The triple-dot notation is a somewhat convienient shortcut though. If we\n> wanted to remove it, we would maybe want to replace it some other\n> functionally equivalent shortcut.\n\nMakes sense. The problem is that there are not many symbols that are\navailable without requiring shell escaping. I don't have a good\nsuggestion.\n\n\n>\n> All this being said, I've sure there are folks in the wild using these\n> notations in scripts and changing would cause disruption. Maybe the Git\n> 3.0 release would indeed be a good time to remove them though.\n>\n> -Justin\n"},{"id":"528971","messageId":"CAESOdVAEN=YeMqozR4438L-U7mZ3nhRnMB5PV_sUPmwuWSkbhQ@mail.gmail.com","threadId":"64328","inReplyTo":"xmqqh5vz7ygc.fsf@gitster.g","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@google.com","sentAt":"2025-10-16T16:38:26Z","receivedAt":"2025-10-16T16:38:39Z","isPatch":true,"sender":{"key":"martinvonz@google.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, 16 Oct 2025 at 06:44, Junio C Hamano wrote:\n>\n> \"brian m. carlson\" writes:\n>\n> >> +Support for \"git diff X..Y\" syntax will be removed. Use \"git diff X Y\" instead.\n> >> +This will open up the syntax for a more consistent interpretation of\n> >> +\"git diff $(git merge-base X Y) Y\".\n> >\n> > I feel like this is going to break a whole lot of existing scripts and\n> > probably more than a few forges as well. It seems especially bad that\n> > we would add it back in the future with a completely different meaning,\n> > since we'll have some people that use 10-year LTS distros that go from,\n> > say, Git 2.51 to Git 3.xx, where the latter reintroduces the syntax with\n> > different semantics.\n> >\n> > We've never really changed the meaning of things like revisions or\n> > revision-adjacent code in the past and I think those kinds of things\n> > we're pretty much stuck with forever. With that in mind, I don't think\n> > this is a good idea.\n>\n> I do not think X..Y (or X...Y), if accepted by commands, would never\n> change their meanings in the middle of the commands' lives.\n> Teaching \"git diff\" to complain and barf on X..Y is a possibility,\n> but to do the same for X...Y, we would need to come up with an\n> alternative syntax first.\n>\n> The same for \"git checkout master...\" that detaches HEAD at the\n> fork point of the current topic (so that I can \"git am\" in a new\n> iteration of patches on top).\n\nI couldn't get this to work:\n\n$ git checkout main... --\nfatal: invalid reference: main...\n\nBut don't worry about it. I think your point about there being other\ncommands that support the triple-dot syntax is still valid.\n\n> As the syntax \"git diff master...\"\n> is symmetric with it, if one were to change, both should change to\n> the same.\n\nAgreed. Some syntax for getting the merge base revision makes sense.\n\n>\n> Thanks.\n>\n>\n"},{"id":"528973","messageId":"xmqqy0pa7pkn.fsf@gitster.g","threadId":"64328","inReplyTo":"xmqqh5vz7ygc.fsf@gitster.g","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-16T16:56:40Z","receivedAt":"2025-10-16T16:56:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I do not think X..Y (or X...Y), if accepted by commands, would never\n> change their meanings in the middle of the commands' lives.\n\nSorry, double-negation bites again. Please drop \"not\" from \"I do not\nthink\" when you are reading the above.\n\n> Teaching \"git diff\" to complain and barf on X..Y is a possibility,\n> but to do the same for X...Y, we would need to come up with an\n> alternative syntax first.\n>\n> The same for \"git checkout master...\" that detaches HEAD at the\n> fork point of the current topic (so that I can \"git am\" in a new\n> iteration of patches on top). As the syntax \"git diff master...\"\n> is symmetric with it, if one were to change, both should change to\n> the same.\n>\n> Thanks.\n"},{"id":"528974","messageId":"d47e137b-c34d-49c9-bf45-226cbcdba416@app.fastmail.com","threadId":"64328","inReplyTo":"CAESOdVAEN=YeMqozR4438L-U7mZ3nhRnMB5PV_sUPmwuWSkbhQ@mail.gmail.com","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-16T17:02:06Z","receivedAt":"2025-10-16T17:02:42Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 16, 2025, at 18:38, Martin von Zweigbergk wrote:\n> On Thu, 16 Oct 2025 at 06:44, Junio C Hamano wrote:\n>>[snip]\n>>\n>> The same for \"git checkout master...\" that detaches HEAD at the\n>> fork point of the current topic (so that I can \"git am\" in a new\n>> iteration of patches on top).\n>\n> I couldn't get this to work:\n>\n> $ git checkout main... --\n> fatal: invalid reference: main...\n\n`git checkout X...` works for me. Apparently it is this part of the\ndoc: “As a special case, you may use ... [...]”\n\n>\n> But don't worry about it. I think your point about there being other\n> commands that support the triple-dot syntax is still valid.\n>\n>> As the syntax \"git diff master...\"\n>> is symmetric with it, if one were to change, both should change to\n>> the same.\n>[snip]\n"},{"id":"528976","messageId":"CAESOdVCQR=z95MK1oHZO4_iBXS8Z9uz4Fs0gDDX+BfaG9_3=ag@mail.gmail.com","threadId":"64328","inReplyTo":"d47e137b-c34d-49c9-bf45-226cbcdba416@app.fastmail.com","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@google.com","sentAt":"2025-10-16T17:12:21Z","receivedAt":"2025-10-16T17:12:34Z","isPatch":true,"sender":{"key":"martinvonz@google.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, 16 Oct 2025 at 10:02, Kristoffer Haugsbakk\n wrote:\n>\n> On Thu, Oct 16, 2025, at 18:38, Martin von Zweigbergk wrote:\n> > On Thu, 16 Oct 2025 at 06:44, Junio C Hamano wrote:\n> >>[snip]\n> >>\n> >> The same for \"git checkout master...\" that detaches HEAD at the\n> >> fork point of the current topic (so that I can \"git am\" in a new\n> >> iteration of patches on top).\n> >\n> > I couldn't get this to work:\n> >\n> > $ git checkout main... --\n> > fatal: invalid reference: main...\n>\n> `git checkout X...` works for me. Apparently it is this part of the\n> doc: “As a special case, you may use ... [...]”\n\nOh, I think I know what the problem is. The reason I tried it was that\nI was curious how it would behave when there are multiple merge bases,\nso I had set up a repo like that. Then I got this:\n\n```\n$ git checkout main...\nerror: pathspec 'main...' did not match any file(s) known to git\n$ git checkout main... --\nfatal: invalid reference: main...\n```\n\nI didn't expect those messages to mean \"the common ancestor is\nambiguous\" so I didn't think to try with an unambiguous common\nancestor.\n\n>\n> >\n> > But don't worry about it. I think your point about there being other\n> > commands that support the triple-dot syntax is still valid.\n> >\n> >> As the syntax \"git diff master...\"\n> >> is symmetric with it, if one were to change, both should change to\n> >> the same.\n> >[snip]\n"},{"id":"528980","messageId":"de772df7-9b73-405b-91fd-8acd5d76fad6@app.fastmail.com","threadId":"64328","inReplyTo":"CAESOdVAHt8nUQRE64RXwS4FiO1=Qy8EPamDwaPqUrHvx7bKCEQ@mail.gmail.com","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-16T17:42:03Z","receivedAt":"2025-10-16T17:42:25Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 16, 2025, at 01:06, Martin von Zweigbergk wrote:\n> On Wed, 15 Oct 2025 at 15:19, Junio C Hamano wrote:\n>>[snip]\n>>\n>> In any case, a declaration that does not come with code changes that\n>> are protected by WITH_BREAKING_CHANGES CPP macro is a patch that is\n>> not quite ready to be applied.\n>\n> Yeah, this was meant as a discussion starter. I assumed I had missed a\n> few things as I'm not very familiar with how things are done here. I'm\n> happy to add that WITH_BREAKING_CHANGES macro if there's a V2.\n\nIs one potential outcome just to deprecate the notations without slating\nthem for removal right away? According to the current document it seems\nthat only `core.commentString=auto` has been both deprecated and slated\nfor removal during the same release cycle. It looks like everything else\nwas deprecated for a good while before the Git 3.0 plan.\n\nMaybe ref files → reftable as well although that doesn’t\ndeprecate anything.\n"},{"id":"529007","messageId":"CALnO6CBaTUzFFB+h5aXN2GuNwm2oyk5ZNEy8u9=80zwQjdfsOQ@mail.gmail.com","threadId":"64328","inReplyTo":"CAESOdVAHt8nUQRE64RXwS4FiO1=Qy8EPamDwaPqUrHvx7bKCEQ@mail.gmail.com","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-16T20:32:56Z","receivedAt":"2025-10-16T20:33:09Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Wed, Oct 15, 2025 at 7:07 PM Martin von Zweigbergk\n wrote:\n>\n> On Wed, 15 Oct 2025 at 15:19, Junio C Hamano wrote:\n> >\n> > \"Martin von Zweigbergk via GitGitGadget\" \n> > writes:\n> >\n> > > From: Martin von Zweigbergk \n> > >\n> > > The `git diff X..Y` syntax is quite misleading because it looks like\n> > > it shows the diff of the commits in the X..Y range but it actually\n> > > shows the diff from X to Y. IMO, if that syntax is supported, it\n> > > should show a diff from the merge base of X and Y to Y. I hope Git 3.0\n> > > is a good time to remove support for the current syntax and\n> > > semantics. Then we can perhaps add the syntax back later with less\n> > > surprising semantics.\n> > >\n> > > Signed-off-by: Martin von Zweigbergk \n> > > ---\n> > > BreakingChanges: say that git diff X..Y syntax will be removed in 3.0\n> >\n> > I like it in prinicple and I do wish that we didn't do the lazy\n> > thing when we did the command line parser for \"git diff\" (we had\n> > revision range parser, so we just reused it instead of doing our own\n> > for \"git diff\"). But real life may bite us back.\n>\n> Ah, so that's where it came from. Thanks for explaining. Speaking of\n> revision range parsers, teaching Git something like Mercurial's or\n> jj's \"revsets\" languages is one reason I would like to get rid of the\n> `git diff X..Y` syntax here. I haven't done a comprehensive analysis\n> but this is the only place I've noticed where we would need a breaking\n> change if we ever wanted to teach Git revsets. (I'm not volunteering\n> my time to work on such a project. I just think it would be nice if\n> someone did :) )\n\nBuried in my todo list is a goal to teach Git about JJ's \"::\" syntax\n:) Fortunately, I don't think that requires this particular change\n(which I'm otherwise in favor of).\n\n\n-- \nD. Ben Knoble\n"},{"id":"529008","messageId":"CALnO6CDH8i0++gTXZCXScLpXnvKTXN5=fYxLJ4W+mgfcSaZt_Q@mail.gmail.com","threadId":"64328","inReplyTo":"xmqqh5vz7ygc.fsf@gitster.g","subject":"Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-16T20:42:03Z","receivedAt":"2025-10-16T20:42:17Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Thu, Oct 16, 2025 at 9:47 AM Junio C Hamano wrote:\n>\n> \"brian m. carlson\" writes:\n>\n> >> +Support for \"git diff X..Y\" syntax will be removed. Use \"git diff X Y\" instead.\n> >> +This will open up the syntax for a more consistent interpretation of\n> >> +\"git diff $(git merge-base X Y) Y\".\n> >\n> > I feel like this is going to break a whole lot of existing scripts and\n> > probably more than a few forges as well. It seems especially bad that\n> > we would add it back in the future with a completely different meaning,\n> > since we'll have some people that use 10-year LTS distros that go from,\n> > say, Git 2.51 to Git 3.xx, where the latter reintroduces the syntax with\n> > different semantics.\n> >\n> > We've never really changed the meaning of things like revisions or\n> > revision-adjacent code in the past and I think those kinds of things\n> > we're pretty much stuck with forever. With that in mind, I don't think\n> > this is a good idea.\n>\n> I do not think X..Y (or X...Y), if accepted by commands, would never\n> change their meanings in the middle of the commands' lives.\n> Teaching \"git diff\" to complain and barf on X..Y is a possibility,\n> but to do the same for X...Y, we would need to come up with an\n> alternative syntax first.\n\nIsn't the alternative syntax\n\n git diff --merge-base X Y\n\n? That's what the manual says, at any rate.\n\n> The same for \"git checkout master...\" that detaches HEAD at the\n> fork point of the current topic (so that I can \"git am\" in a new\n> iteration of patches on top). As the syntax \"git diff master...\"\n> is symmetric with it, if one were to change, both should change to\n> the same.\n\nAs a gut reaction, this is a bit apples-to-oranges: for me, the issue\nwith the diff notations is that \"git diff X...Y\" shows changes \"only\non the Y side\" (where as with rev-list/log/etc. it does \"both sides\");\ncontrast with \"X..Y\" in both scenarios.\n\nMeanwhile, checkout is only ever really expecting a single point to\ncheckout. Still, perhaps a different notation that means \"merge-base\"\nis warranted for that case, making the following equivalent with my\nhypothetical syntax:\n\n git log X...Y\n git log X Y X^{merge-Y}\n git log X Y X^{M-Y} # hyphen optional here? \"merge/M\" vs \"mergebase/MB\"?\n\nInspiration from X^{/search}, of course, since any non- and\nnon-\"/\" prefix is effectively unused. Anyway, then you'd write\n\n git checkout master^{M}\n\nor some such (where the \"empty\" bit becomes a synonym for HEAD as usual).\n\n-- \nD. Ben Knoble\n"}]}