Re: [PATCH v2 0/3] mingw: include the Python parts in the build

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 29 Jul 2022, Johannes Schindelin via GitGitGadget wrote:
>
>> Range-diff vs v1:
>>
>>  -:  ----------- > 1:  5d9b087625a windows: include the Python bits when building Git for Windows
>>  -:  ----------- > 2:  019fb837d68 mingw: remove unneeded `NO_GETTEXT` directive
>>  1:  a5739b9cce8 ! 3:  7dc0a1a9aa8 mingw: include the Python parts in the build
> ...
> Oh, that's funny. This is actually the first time I personally see
> `range-diff` matching up a wrong patch pair (because it really looks for
> the minimal diff between the diffs). It is of course nonsense to match up
> the original patch with the `NO_CURL` patch.

It would depend on the creation-factor number, I suspect.  To me, it
does not seem to match anything at all, but with an unreasonably
high number like 9999, I see 1 corresponds to the old one, with the
other two follow-up patch as new.

As the maintainer, I mostly use range-diff to compare two iterations
of a single topic, and not "compare 'seen' from 24 hours ago with
'seen' I just rebuilt, so that I can match up everything in an
uncontrolled mess", so the optimum factor number would be different
for my usecase from the one used for general use (which is
documented to be 60).

The "maintainer" use case compares two iterations that are known and
expected to have corresponding patches (and no corresponding one
means either dropped or added), and come to think of it, the use
case for submitter to run "format-patch --range-diff" shares exactly
the same expectation.  It is very different from "pick corresponding
patches from two piles of many unrelated topics" use case, in which
"range-diff" proper can be used.

Perhaps the default used for "format-patch" should become different
and set a lot higher than the default for "range-diff" proper?