On Wed, May 30, 2018 at 3:03 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> On Wed, May 30, 2018 at 1:03 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>> The --range-diff option introduces the embedded range-diff generically
>> as "Changes since previous version:", however, we can do better when
>> --reroll-count is specified by emitting "Changes since v{n}:" instead.
>
> A very similar option that I used before finding reroll count is
> --subject-prefix
> I still use that for RFC/WIP tags, but I sometimes used it with "PATCHv2"
> as an argument, too.
>
> Would we want to extend the niceties of this patch to that workflow?
I would not include such functionality directly in this patch, as the
two ideas are only superficially related ("computing the previous
version number by *some* mechanism") but not related in actual
implementation.
Computing the previous version number by consulting --reroll-count, as
done by this patch, is deterministic and was just low-hanging fruit.
What you suggest probably involves heuristics and parsing, thus ought
to be done in its own patch (or patches). It's also the sort of
incremental improvement that can be done later (rather than in this
initial implementation) if someone deems it desirable.
BTW: You can use "git format-patch --rfc" for RFC patches (in fact, I
did so for this series).
> Unrelated to this patch: how does this series cope with range diffs
> that are not in commit-ish but patches on the file system?
I'm not following. Can you provide a concrete example to get me up to speed?
