Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0

From: Martin von Zweigbergk <martinvonz@google.com>
Date: Oct 15, 2025, 23:06 UTC
Message-ID: <CAESOdVAHt8nUQRE64RXwS4FiO1=Qy8EPamDwaPqUrHvx7bKCEQ@mail.gmail.com>
In-Reply-To: <xmqq4irzu7st.fsf@gitster.g>

On Wed, 15 Oct 2025 at 15:19, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

>
> "Martin von Zweigbergk via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > 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
>
> I like it in prinicple and I do wish that we didn't do the lazy
> thing when we did the command line parser for "git diff" (we had
> revision range parser, so we just reused it instead of doing our own
> for "git diff").  But real life may bite us back.

Ah, so that's where it came from. Thanks for explaining. Speaking of revision range parsers, teaching Git something like Mercurial's or jj's "revsets" languages is one reason I would like to get rid of the `git diff X..Y` syntax here. I haven't done a comprehensive analysis but this is the only place I've noticed where we would need a breaking change if we ever wanted to teach Git revsets. (I'm not volunteering my time to work on such a project. I just think it would be nice if someone did :) )

>
> In any case, a declaration that does not come with code changes that
> are protected by WITH_BREAKING_CHANGES CPP macro is a patch that is
> not quite ready to be applied.

Yeah, this was meant as a discussion starter. I assumed I had missed a few things as I'm not very familiar with how things are done here. I'm happy to add that WITH_BREAKING_CHANGES macro if there's a V2.