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

[Eric Sunshine <sunshine@sunshineco.com>]

On Thu, Nov 12, 2020 at 12:57 PM Junio C Hamano <gitster@pobox.com> wrote:
> 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.)