Re: [RFC PATCH 4/5] format-patch: teach --range-diff to respect -v/--reroll-count

From: Eric Sunshine <sunshine@sunshineco.com>
Date: May 30, 2018, 20:44 UTC
Message-ID: <CAPig+cRh02976beGp5c5Sw5=h86VgNZgVreCHh38QKP5udJeGg@mail.gmail.com>
In-Reply-To: <CAGZ79kZ2MKpjwwx0+ZsPZ9bFu_ersPJ=kKPYWRmWYjJ8yoVhuA@mail.gmail.com>

On Wed, May 30, 2018 at 3:03 PM, Stefan Beller <sbeller@google.com> wrote:

Show 11 quoted lines

> On Wed, May 30, 2018 at 1:03 AM, Eric Sunshine <sunshine@sunshineco.com> 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?