From: ZheNing Hu <adlternative@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Denton Liu <liu.denton@gmail.com>,
ZheNing Hu via GitGitGadget <gitgitgadget@gmail.com>,
Git List <git@vger.kernel.org>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v2] format-patch: allow a non-integral version numbers
Date: Thu, 4 Mar 2021 10:08:26 +0800 [thread overview]
Message-ID: <CAOLTT8RdXC+KQNupU1TQdPh-tQO+syd6WJe85GzieE3uWt2ibA@mail.gmail.com> (raw)
In-Reply-To: <xmqqpn0fg2ls.fsf@gitster.c.googlers.com>
Junio C Hamano <gitster@pobox.com> 于2021年3月4日周四 上午8:54写道:
>
> Denton Liu <liu.denton@gmail.com> writes:
>
> > Hmm, others may disagree but I don't really like the idea of
> > `--previous-count`. It may be useful for populating "Range-diff vs <n>"
> > instead of just "Range-diff" but I don't think it's worth the cost of
> > maintaining this option.
>
> It really depends on the target audience. As a reviewer who may be
> too busy to read every iteration of a series, I would probably find
> it useless if it gives just "range-diff" or "range-diff with last"
> without saying which exact round. Obviously, if you are not doing
> range-diff, it will not be an issue. If the patch requires (I
> didn't read the latest one) the previous-count to be given when
> range-diff or interdiff is not requested, it should probably be
> fixed.
>
> I am also OK with any design decision, as long as it will not close
> the door for the occasionally requested feature to carry over cover
> letter material from the previous round to the current one.
>
> Thanks.
What we are arguing now is whether it is necessary to add
"aginst v<previous_count>" to the patch when the non-integer version
number + rangediff/interdiff is required. Denton's point of view may be
similar to that of Eric before.
Here are my personal thoughts:
Personally, I may use GGG more. When I see a title like "Range-diff vs v1:",
I can know that this is a change from the previous v1, and it may be better
than "Range-diff again v1" To be more specific, but if it is a small patch such
as "v1.2", we use previous_count to tell the reviewer that this is a
range-diff
change from "v1.1" or other versions.
Of course this `previous count` can be used in a very small range, but
I think it
doesn't hurt to keep it, because even if you don't use it, `format
patch` will still
output "Range-diff", which will not break any known functions. It can
only be said
that `previous count` provides an option for submitters to know the
previous version
for reviewers. In this regard, I agree with Junio's point of view.
Thanks.
next prev parent reply other threads:[~2021-03-04 2:10 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
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 [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOLTT8RdXC+KQNupU1TQdPh-tQO+syd6WJe85GzieE3uWt2ibA@mail.gmail.com \
--to=adlternative@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=liu.denton@gmail.com \
--cc=sunshine@sunshineco.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).