From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Thu, 16 Oct 2025 20:42:03 GMT
Subject: Re: [PATCH] BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0
Message-ID: <CALnO6CDH8i0++gTXZCXScLpXnvKTXN5=fYxLJ4W+mgfcSaZt_Q@mail.gmail.com>
In-Reply-To: <xmqqh5vz7ygc.fsf@gitster.g>

On Thu, Oct 16, 2025 at 9:47 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "brian m. carlson" <sandals@crustytoothpaste.net> 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.

Isn't the alternative syntax

    git diff --merge-base X Y

? That's what the manual says, at any rate.

> 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).  As the syntax "git diff master..."
> is symmetric with it, if one were to change, both should change to
> the same.

As a gut reaction, this is a bit apples-to-oranges: for me, the issue
with the diff notations is that "git diff X...Y" shows changes "only
on the Y side" (where as with rev-list/log/etc. it does "both sides");
contrast with "X..Y" in both scenarios.

Meanwhile, checkout is only ever really expecting a single point to
checkout. Still, perhaps a different notation that means "merge-base"
is warranted for that case, making the following equivalent with my
hypothetical syntax:

    git log X...Y
    git log X Y X^{merge-Y}
    git log X Y X^{M-Y} # hyphen optional here? "merge/M" vs "mergebase/MB"?

Inspiration from X^{/search}, of course, since any non-<type> and
non-"/" prefix is effectively unused. Anyway, then you'd write

    git checkout master^{M}

or some such (where the "empty" bit becomes a synonym for HEAD as usual).

-- 
D. Ben Knoble