Re: [RFC PATCH 4/5] format-patch: teach --range-diff to respect -v/--reroll-count
On Wed, May 30, 2018 at 5:03 PM, Stefan Beller wrote: > On Wed, May 30, 2018 at 1:44 PM, Eric Sunshine > wrote: >>> 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? > > I was just wondering if things like > > git format-patch --range-diff=v3-00*.patch --reroll-count=4 -3 > > would be supported, but that doesn't seem to be the case, now that I read > the whole series. I don't think it is crucial to support right now. Okay, that's what I thought you meant (upon thinking harder about it after hitting Send). git-range-diff doesn't support that mode of operation (nor does 'tbdiff', as far as I can tell), so as a thin wrapper around git-range-diff, "git format-patch --range-diff" doesn't support it either. Perhaps that sort of functionality could implement later by someone, if desired. In the meantime, the following (manual procedure) would approximate it: git checkout --detach git am v3-00*.patch git format-patch --range-diff=... > This whole series is reviewed by me and I think it is good for inclusion > once we have a reroll of the range-diff series and aligned the command > name to call. Thanks.
Re: [RFC PATCH 4/5] format-patch: teach --range-diff to respect -v/--reroll-count
On Wed, May 30, 2018 at 1:44 PM, Eric Sunshine wrote: >> 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? I was just wondering if things like git format-patch --range-diff=v3-00*.patch --reroll-count=4 -3 would be supported, but that doesn't seem to be the case, now that I read the whole series. I don't think it is crucial to support right now. This whole series is reviewed by me and I think it is good for inclusion once we have a reroll of the range-diff series and aligned the command name to call. Thanks, Stefan
Re: [RFC PATCH 4/5] format-patch: teach --range-diff to respect -v/--reroll-count
On Wed, May 30, 2018 at 3:03 PM, Stefan Beller wrote:
> On Wed, May 30, 2018 at 1:03 AM, Eric Sunshine
> 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?
Re: [RFC PATCH 4/5] format-patch: teach --range-diff to respect -v/--reroll-count
On Wed, May 30, 2018 at 1:03 AM, Eric Sunshine 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?
Unrelated to this patch: how does this series cope with range diffs
that are not in commit-ish but patches on the file system?
[RFC PATCH 4/5] format-patch: teach --range-diff to respect -v/--reroll-count
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.
Signed-off-by: Eric Sunshine
---
builtin/log.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/log.c b/builtin/log.c
index e38cf06050..3089d3a50a 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1121,7 +1121,11 @@ static void make_cover_letter(struct rev_info *rev, int
use_stdout,
if (diff.len) {
FILE *fp = rev->diffopt.file;
- fputs(_("Changes since previous version:"), fp);
+ if (rev->reroll_count <= 0)
+ fputs(_("Changes since previous version:"), fp);
+ else /* RFC may be v0, so allow -v1 to diff against v0 */
+ fprintf(fp, _("Changes since v%d:"),
+ rev->reroll_count - 1);
fputs("\n\n", fp);
fputs(diff.buf, fp);
fputc('\n', fp);
--
2.17.1.1235.ge295dfb56e
