Re: git format-patch --range-diff bug?

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Nov 12, 2020, 18:32 UTC
Message-ID: <CAPig+cT1zDT1iqRqO-4U8Rwq7p=MFm5Bkn990AVbxMHqp=knmg@mail.gmail.com>
In-Reply-To: <xmqqk0uqjw4l.fsf@gitster.c.googlers.com>

On Thu, Nov 12, 2020 at 12:57 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> SZEDER Gábor <szeder.dev@gmail.com> writes:
> >       git range-diff v1...v2 &&
> >       git format-patch -1 --range-diff=v1...v2 v2 &&
>
> The other day I did something similar and ended up with
>
>         git format-patch --range-diff=v1 v1..v2
>
> Would it help not to use the three-dot form?  From my reading of
> "git format-patch --range-diff=<previous>" description, it only
> needs to give a single range (i.e. previous side of series of
> commits) as the other range to be compared are by definition the
> patches you are producing, while v1...v2 syntax is to give two
> ranges with one option.  So...

Indeed. It's not clear (at least to me) how git-format-patch's --range-diff option should interpret a 3-dot range, thus the implementation explicitly supports only a single revision or a 2-dot range, and the documentation reflects this.

It turns out, as you discovered, that the implementation is a bit deficient in that it doesn't outright reject a 3-dot range, and instead gets tripped up by:

     int prev_is_range = !!strstr(prev, "..");

which accidentally also matches a 3-dot range, with the result that the 3-dot range gets passed into the lower-level range-diff machinery which then forwards the 3-dot range to git-log. The git-range-diff command, on the other hand, interprets a 3-dot range manually so such a range doesn't make it down to the lower-level range-diff machinery.

I haven't fully thought it through yet, but at this point, the best "fix" likely would be for `git format-patch --range-diff` to error out when it sees a 3-dot range. (Unless there is some other intuitive interpretation of a 3-dot range which escapes me.)