From: Martin von Zweigbergk Date: Thu, 16 Oct 2025 16:38:26 GMT Subject: Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0 Message-ID: In-Reply-To: On Thu, 16 Oct 2025 at 06:44, Junio C Hamano wrote: > > "brian m. carlson" writes: > > >> +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. > > I do not think X..Y (or X...Y), if accepted by commands, would never > change their meanings in the middle of the commands' lives. > Teaching "git diff" to complain and barf on X..Y is a possibility, > but to do the same for X...Y, we would need to come up with an > alternative syntax first. > > The same for "git checkout master..." that detaches HEAD at the > fork point of the current topic (so that I can "git am" in a new > iteration of patches on top). I couldn't get this to work: $ git checkout main... -- fatal: invalid reference: main... But don't worry about it. I think your point about there being other commands that support the triple-dot syntax is still valid. > As the syntax "git diff master..." > is symmetric with it, if one were to change, both should change to > the same. Agreed. Some syntax for getting the merge base revision makes sense. > > Thanks. > >