Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Oct 15, 2025, 22:28 UTC
- Message-ID
- <aPAgBPLH4QYa0ceP@fruit.crustytoothpaste.net>
- In-Reply-To
- <pull.1989.git.1760566054455.gitgitgadget@gmail.com>
On 2025-10-15 at 22:07:34, Martin von Zweigbergk via GitGitGadget wrote:
Show 32 quoted lines
> From: Martin von Zweigbergk <martinvonz@google.com> > > The `git diff X..Y` syntax is quite misleading because it looks like > it shows the diff of the commits in the X..Y range but it actually > shows the diff from X to Y. IMO, if that syntax is supported, it > should show a diff from the merge base of X and Y to Y. I hope Git 3.0 > is a good time to remove support for the current syntax and > semantics. Then we can perhaps add the syntax back later with less > surprising semantics. > > Signed-off-by: Martin von Zweigbergk <martinvonz@google.com> > --- > BreakingChanges: say that git diff X..Y syntax will be removed in 3.0 > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1989%2Fmartinvonz%2Fmz%2Fwtmnpolouvvz-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1989/martinvonz/mz/wtmnpolouvvz-v1 > Pull-Request: https://github.com/gitgitgadget/git/pull/1989 > > Documentation/BreakingChanges.adoc | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc > index 90b53abcea..93fb968840 100644 > --- a/Documentation/BreakingChanges.adoc > +++ b/Documentation/BreakingChanges.adoc > @@ -114,6 +114,10 @@ applications and forges. > + > There is no plan to deprecate the "sha1" object format at this point in time. > + > +Support for "git diff X..Y" syntax will be removed. Use "git diff X Y" instead. > +This will open up the syntax for a more consistent interpretation of > +"git diff $(git merge-base X Y) Y".
I feel like this is going to break a whole lot of existing scripts and probably more than a few forges as well. It seems especially bad that we would add it back in the future with a completely different meaning, since we'll have some people that use 10-year LTS distros that go from, say, Git 2.51 to Git 3.xx, where the latter reintroduces the syntax with different semantics.
We've never really changed the meaning of things like revisions or revision-adjacent code in the past and I think those kinds of things we're pretty much stuck with forever. With that in mind, I don't think this is a good idea.
-- brian m. carlson (they/them) Toronto, Ontario, CA