All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Glen Choo <chooglen@google.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH v2] MyFirstContribution: Document --range-diff option when writing v2
Date: Tue, 21 Sep 2021 00:59:01 -0400	[thread overview]
Message-ID: <CAPig+cR8ZRGVrNsf6nbBsjuLt768fr=SB+bY_bD+tQpkzrL7FA@mail.gmail.com> (raw)
In-Reply-To: <20210920223226.25877-1-chooglen@google.com>

On Mon, Sep 20, 2021 at 10:22 PM Glen Choo <chooglen@google.com> wrote:
> In the "Sending v2" section, readers are directed to create v2 patches
> without using --range-diff. However, it is customary to include a
> range-diff against the v1 patches as a reviewer aid.
>
> Update the "Sending v2" section to suggest a simple workflow that uses
> the --range-diff option. Also include some explanation for -v2 and
> --range-diff to help the reader understand the importance.
>
> Signed-off-by: Glen Choo <chooglen@google.com>
> ---
> diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
> @@ -1029,22 +1029,41 @@ kidding - be patient!)
> +Make your changes with `git rebase -i`. Once you're ready with the next
> +iteration of your patch, the process is fairly similar to before. Generate your
> +patches again, but with some new flags:

I wonder if "Make your changes with `git rebase -i`" is a bit too
terse for newcomers to understand. Perhaps a bit more verbose:

    Refine your patch series by using `git rebase -i` to adjust
    commits based upon reviewer comments. Once the patch series is
    ready for submission, generate your patches again, but with some
    new flags:

>  ----
> +$ git format-patch -v2 --cover-letter -o psuh/ --range-diff master..psuh-v1 master..
>  ----
>
> +The `--range-diff master..psuh-v1` parameter tells `format-patch` to include a
> +range-diff between `psuh-v1` and `psuh` (see linkgit:git-range-diff[1]). This
> +helps tell reviewers about the differences between your v1 and v2 patches.

This leaves dangling the question of where the range-diff is placed. Maybe say:

    ... tells `format-patch` to include a range-diff between ... in
    the cover letter.

> +The `-v2` parameter tells `format-patch` to output "v2" patches. For instance,
> +you may notice that your v2 patches, are all named like
> +`v2-000n-my-commit-subject.patch`. `-v2` will also format your patches by
> +prefixing them with "[PATCH V2]" instead of "[PATCH]", and your range-diff will
> +be prefaced with "Range-diff against v1".

s/V2/v2/

> +Afer you run this command, `format-patch` will output the patches to the `psuh/`
> +directory, alongside the v1 patches. Using a single directory makes it easy to
> +refer to the old v1 patches while proofreading the v2 patches, but you will need
> +to be careful to send out only the v2 patches. We will use a pattern like
> +"psuh/v2-*.patch" ("psuh/*.patch" would match v1 and v2 patches).

To avoid any sort of confusion, perhaps:

    ... "psuh/v2-*.patch" (not "psuh/*.patch" which would match v1 and
    v2 patches)

  reply	other threads:[~2021-09-21  4:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13 19:48 [PATCH] MyFirstContribution: Document --range-diff option when writing v2 Glen Choo
2021-09-13 20:00 ` Eric Sunshine
2021-09-13 20:05   ` Eric Sunshine
2021-09-13 21:39 ` Junio C Hamano
2021-09-14 17:21   ` Glen Choo
2021-09-14 21:39     ` Junio C Hamano
2021-09-14  2:43 ` Bagas Sanjaya
2021-09-14  3:46   ` Eric Sunshine
2021-09-14  3:55     ` Bagas Sanjaya
2021-09-20 22:32 ` [PATCH v2] " Glen Choo
2021-09-21  4:59   ` Eric Sunshine [this message]
2021-09-21 17:31     ` Glen Choo
2021-09-21 17:33     ` Glen Choo
2021-09-21 17:34     ` Glen Choo
2021-09-21  5:33   ` Bagas Sanjaya
2021-09-21 17:58     ` Glen Choo
2021-09-22 18:54     ` Junio C Hamano
2021-09-22 12:18   ` Philip Oakley
2021-09-22 17:34     ` Glen Choo
2021-09-23 13:44       ` Philip Oakley
2021-09-23  5:46     ` Bagas Sanjaya
2021-09-22 20:22   ` [PATCH v3] " Glen Choo

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+cR8ZRGVrNsf6nbBsjuLt768fr=SB+bY_bD+tQpkzrL7FA@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=chooglen@google.com \
    --cc=git@vger.kernel.org \
    /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.