Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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?
