All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: ZheNing Hu via GitGitGadget <gitgitgadget@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Denton Liu <liu.denton@gmail.com>,
	ZheNing Hu <adlternative@gmail.com>
Subject: Re: [PATCH] format-patch: allow a non-integral version numbers
Date: Thu, 25 Feb 2021 12:56:48 -0500	[thread overview]
Message-ID: <CAPig+cQcyJJnuOq9wtJjgEi7OgO39wBf+hHkVxaQ4z-RehvgNA@mail.gmail.com> (raw)
In-Reply-To: <pull.885.git.1614269753194.gitgitgadget@gmail.com>

On Thu, Feb 25, 2021 at 11:19 AM ZheNing Hu via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> Usually we can only use `format-patch -v<n>` to generate integral
> version numbers patches, but if we can provide `format-patch` with
> non-integer versions numbers of patches, this may help us to send patches
> such as "v1.1" versions sometimes.

On the Git project itself, fractional or non-numeric re-roll "numbers"
are not necessarily encouraged[1], so this feature may not be
particularly useful here, though perhaps some other project might
benefit from it(?). Usually, you would want to justify why the change
is desirable. Denton did give a bit of justification in his
proposal[2] for this feature, so perhaps update this commit message by
copying some of what he wrote as justification.

[1]: I think I've only seen Denton send fractional re-rolls; other
people sometimes send a periodic "fixup!" patch, but both approaches
place extra burden on the project maintainer than merely re-rolling
the entire series with a new integer re-roll count.

[2]: https://github.com/gitgitgadget/git/issues/882

> Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> ---
> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
> @@ -215,12 +215,12 @@ populated with placeholder text.
>  -v <n>::
>  --reroll-count=<n>::
> -       Mark the series as the <n>-th iteration of the topic. The
> +       Mark the series as the specified version of the topic. The
>         output filenames have `v<n>` prepended to them, and the
>         subject prefix ("PATCH" by default, but configurable via the
>         `--subject-prefix` option) has ` v<n>` appended to it.  E.g.
> -       `--reroll-count=4` may produce `v4-0001-add-makefile.patch`
> -       file that has "Subject: [PATCH v4 1/20] Add makefile" in it.
> +       `--reroll-count 4.4` may produce `v4.4-0001-add-makefile.patch`
> +       file that has "Subject: [PATCH v4.4 1/20] Add makefile" in it.

I'm not sure we want to encourage the use of fractional re-roll counts
by using it in an example like this. It would probably be better to
leave the example as-is. If you really want people to know that
fractional re-roll counts are supported, perhaps add separate sentence
saying that they are.

> diff --git a/builtin/log.c b/builtin/log.c
> @@ -1662,13 +1662,13 @@ static void print_bases(struct base_tree_info *bases, FILE *file)
> -static const char *diff_title(struct strbuf *sb, int reroll_count,
> +static const char *diff_title(struct strbuf *sb, const char *reroll_count,
>                        const char *generic, const char *rerolled)
>  {
> -       if (reroll_count <= 0)
> +       if (!reroll_count)
>                 strbuf_addstr(sb, generic);
>         else /* RFC may be v0, so allow -v1 to diff against v0 */
> -               strbuf_addf(sb, rerolled, reroll_count - 1);
> +               strbuf_addf(sb, rerolled, "last version");
>         return sb->buf;
>  }

There are a couple problems here (at least). First, the string "last
version" should be localizable, `_("last version")`. Second, in
Denton's proposal[2], he suggested using the string "last version"
_only_ if the re-roll count is not an integer. What you have here
applies "last version" unconditionally when -v is used so that the
outcome is _always_ "Range-diff since last version". If that's what
you intend to do, there's no reason to do any sort of interpolation
using the template "Range-diff since %". What Denton had in mind was
this (using pseudo-code):

    if re-roll count not specified:
        message = "Range-diff"
    else if re-roll count is integer:
        message = "Range-diff since v%d", re-roll
    else:
        message = "Range-diff since v%s", re-roll

However, there isn't a good reason to favor "Range-diff since last
version" over the simpler generic message "Range-diff". So, the above
should be collapsed to:

    if re-roll count is specified and integer:
        message = "Range-diff since v%d", re-roll
    else:
        message = "Range-diff"

> @@ -2080,7 +2080,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> -                                            _("Interdiff against v%d:"));
> +                                            _("Interdiff against %s:"));
> @@ -2099,7 +2099,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> -                                            _("Range-diff against v%d:"));
> +                                            _("Range-diff against %s:"));

If you follow my recommendation above using the simplified
conditional, then you don't need to drop the "v" since you won't be
saying "last version".

  reply	other threads:[~2021-02-25 17:58 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 16:15 [PATCH] format-patch: allow a non-integral version numbers ZheNing Hu via GitGitGadget
2021-02-25 17:56 ` Eric Sunshine [this message]
2021-02-27  7:00   ` ZheNing Hu
2021-02-25 18:13 ` Junio C Hamano
2021-02-27  7:30   ` ZheNing Hu
2021-03-17 11:46   ` Đoàn Trần Công Danh
2021-03-17 19:17     ` Junio C Hamano
2021-03-01  8:40 ` [PATCH v2] " ZheNing Hu via GitGitGadget
2021-03-03  3:44   ` Junio C Hamano
2021-03-03  9:02   ` Denton Liu
2021-03-04  0:54     ` Junio C Hamano
2021-03-04  2:08       ` ZheNing Hu
2021-03-04  3:27         ` Eric Sunshine
2021-03-04  8:41           ` Denton Liu
2021-03-04 12:12   ` [PATCH v3] " ZheNing Hu via GitGitGadget
2021-03-04 12:49     ` Denton Liu
2021-03-05  4:56       ` ZheNing Hu
2021-03-05  7:10     ` [PATCH v4] " ZheNing Hu via GitGitGadget
2021-03-15 23:41       ` Eric Sunshine
2021-03-16  5:48         ` ZheNing Hu
2021-03-16  6:15           ` Eric Sunshine
2021-03-17 17:27             ` Junio C Hamano
2021-03-16  8:25       ` [PATCH v5] " ZheNing Hu via GitGitGadget
2021-03-16 23:36         ` Eric Sunshine
2021-03-17  2:05           ` ZheNing Hu
2021-03-18  6:00         ` [PATCH v6] " ZheNing Hu via GitGitGadget
2021-03-19  6:00           ` Eric Sunshine
2021-03-19  7:25             ` ZheNing Hu
2021-03-19 11:21           ` [PATCH v7] " ZheNing Hu via GitGitGadget
2021-03-19 16:01             ` Junio C Hamano
2021-03-20  3:08               ` ZheNing Hu
2021-03-19 17:28             ` Junio C Hamano
2021-03-20  3:04               ` ZheNing Hu
2021-03-20 14:56             ` [PATCH v8] " ZheNing Hu via GitGitGadget
2021-03-20 19:55               ` Junio C Hamano
2021-03-21  2:45                 ` ZheNing Hu
2021-03-21  4:05               ` Eric Sunshine
2021-03-21  5:45                 ` Junio C Hamano
2021-03-21  5:54                   ` Eric Sunshine
2021-03-24  8:46                     ` Denton Liu
2021-03-21  7:22                 ` ZheNing Hu
2021-03-21  9:00               ` [PATCH v9] " ZheNing Hu via GitGitGadget
2021-03-23  5:31                 ` Eric Sunshine
2021-03-23  6:42                   ` Junio C Hamano
2021-03-23  8:53                   ` ZheNing Hu
2021-03-23  9:16                     ` ZheNing Hu
2021-03-23 11:12                 ` [PATCH v10] " ZheNing Hu via GitGitGadget
2021-03-24  3:58                   ` Eric Sunshine
2021-03-24  4:43                     ` ZheNing Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPig+cQcyJJnuOq9wtJjgEi7OgO39wBf+hHkVxaQ4z-RehvgNA@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=adlternative@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=liu.denton@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.