[PATCH v2] Documentation: specify base point when generating MyFirstContribution patchset

[PATCH v2] Documentation: specify base point when generating MyFirstContribution patchset

[Bagas Sanjaya]

Specifying base point (commit hash) can help reviewers and testers
interested on the patchset. Mention how to record it with `--base`
option to `format-patch`.

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 Changes since v1 [1]:
     - Rewording (suggested by Junio).
     - Show command to determine base commit hash and pass it to `--base`
       option.

 [1]:
https://lore.kernel.org/git/f25fae40-0313-287b-5482-1c64cbe8cb64@gmail.com/T/#t

 Documentation/MyFirstContribution.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
index b20bc8e914..5aaf31cb66 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -937,6 +937,23 @@ but want reviewers to look at what they have so far. You can add this flag with
 Check and make sure that your patches and cover letter template exist in the
 directory you specified - you're nearly ready to send out your review!
 
+It would help those who review and test your patches to specify on what
+commit the patches should be applied to. To do so, use the `--base` option
+when running `format-patch`. The option expects hash of the commit the
+patchset is based on. Since we base `psuh` on top of `master`, the base
+commit hash can be determined by: 
+
+----
+$ git show -s --format="%H" master
+----
+
+The output of command above can be passed to `--base` option. Replace `<base>`
+with your own hash:
+
+----
+$ git format-patch --cover-letter --base=<base> -o psuh/ master..psuh
+----
+
 [[cover-letter]]
 === Preparing Email
 

base-commit: 2bd2f258f4195ac54293a3f45b86457c0bd5fc11
-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH v2] Documentation: specify base point when generating MyFirstContribution patchset

[Glen Choo]

Bagas Sanjaya <bagasdotme@gmail.com> writes:

> diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
> index b20bc8e914..5aaf31cb66 100644
> --- a/Documentation/MyFirstContribution.txt
> +++ b/Documentation/MyFirstContribution.txt
> @@ -937,6 +937,23 @@ but want reviewers to look at what they have so far. You can add this flag with
>  Check and make sure that your patches and cover letter template exist in the
>  directory you specified - you're nearly ready to send out your review!
>  
> +It would help those who review and test your patches to specify on what
> +commit the patches should be applied to. To do so, use the `--base` option
> +when running `format-patch`. The option expects hash of the commit the
> +patchset is based on. Since we base `psuh` on top of `master`, the base
> +commit hash can be determined by: 
> +
> +----
> +$ git show -s --format="%H" master
> +----
> +
> +The output of command above can be passed to `--base` option. Replace `<base>`
> +with your own hash:
> +
> +----
> +$ git format-patch --cover-letter --base=<base> -o psuh/ master..psuh
> +----
> +
>  [[cover-letter]]
>  === Preparing Email

This reads quite awkwardly because a few lines above, we already tell
the reader exactly what commands to run:

  Sending emails with Git is a two-part process; before you can prepare the emails
  themselves, you'll need to prepare the patches. Luckily, this is pretty simple:

  ----
  $ git format-patch --cover-letter -o psuh/ master..psuh
  ----

If we do accept this suggestion (and I am not sure if we should, because
as Junio said, there are strong conventions for determining the branch
point), I think this would be easier to follow if we incorporate it into
the existing instructions. Something like..

  Sending emails with Git is a two-part process; before you can prepare the emails
  themselves, you'll need to prepare the patches. Luckily, this is
  pretty simple. First, we'll get the hash of the commit the patchset is
  based on. We call this commit the 'base'.

  ----
  $ git show -s --format="%H" master
  ----

  Now, we'll generate the patches, passing the hash of the 'base' to the
  --base option.

  ----
  $ git format-patch --cover-letter --base=<base> -o psuh/ master..psuh
  ----

  [...describe --base=<base> the way we describe the other options].

Re: [PATCH v2] Documentation: specify base point when generating MyFirstContribution patchset

[Bagas Sanjaya]

On 16/10/21 00.06, Glen Choo wrote:
> This reads quite awkwardly because a few lines above, we already tell
> the reader exactly what commands to run:
> 
>    Sending emails with Git is a two-part process; before you can prepare the emails
>    themselves, you'll need to prepare the patches. Luckily, this is pretty simple:
> 
>    ----
>    $ git format-patch --cover-letter -o psuh/ master..psuh
>    ----
> 
> If we do accept this suggestion (and I am not sure if we should, because
> as Junio said, there are strong conventions for determining the branch
> point), I think this would be easier to follow if we incorporate it into
> the existing instructions. Something like..
> 
>    Sending emails with Git is a two-part process; before you can prepare the emails
>    themselves, you'll need to prepare the patches. Luckily, this is
>    pretty simple. First, we'll get the hash of the commit the patchset is
>    based on. We call this commit the 'base'.
> 
>    ----
>    $ git show -s --format="%H" master
>    ----
> 
>    Now, we'll generate the patches, passing the hash of the 'base' to the
>    --base option.
> 
>    ----
>    $ git format-patch --cover-letter --base=<base> -o psuh/ master..psuh
>    ----
> 
>    [...describe --base=<base> the way we describe the other options].
> 

Actually it is up to contributors whether they want to include `--base` 
or not.

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH v2] Documentation: specify base point when generating MyFirstContribution patchset

[Junio C Hamano]

Bagas Sanjaya <bagasdotme@gmail.com> writes:

> +It would help those who review and test your patches to specify on what
> +commit the patches should be applied to. To do so, use the `--base` option
> +when running `format-patch`. The option expects hash of the commit the
> +patchset is based on. Since we base `psuh` on top of `master`, the base
> +commit hash can be determined by: 
> +
> +----
> +$ git show -s --format="%H" master
> +----

That's a littie bit wasteful.

If we need to teach more stuff (like --format="%H"), one thing that
more directly help this exact use case is to teach

    git merge-base master psuh

here.  But read on.

> +The output of command above can be passed to `--base` option. Replace `<base>`
> +with your own hash:
> +
> +----
> +$ git format-patch --cover-letter --base=<base> -o psuh/ master..psuh
> +----
> +

If we set up the psuh branch correctly, we can use the `--base=auto`
option, which would reduce the number of things readers need to
learn by one.  Then the whole example in this patch can be reduced
to (after dropping "Since we base `psuh` on top of `master`..." at
the end of the previous paragraph):

    patchset is based on.  As we forked `psuh` to build on
    `origin/master`, we can use the `--base=auto` option when
    running the `format-patch` command, like so:

    ----
    $ git format-patch --cover-letter --base=auto -o psuh/ origin/master..psuh
    ----

That is one fewer step the user needs to execute.

This needs one line change in the earlier part of the document (not
touched by the patch under discussion here). 

In the [[setup-workspace]] section, we create the psuh by branching
out of the origin/master (not 'master', so the references to
`master` in the patch under discussion need to be updated, which I
did in the above paragraph already), like so:

    ----
    $ git checkout -b psuh origin/master
    ----

All we need to do is to pass the `-t` option there, i.e.

    ----
    $ git checkout -t -b psuh origin/master
    ----
    
to make the --base=auto work, I think.

Thanks.


[Addendum]

Also, if the tutorial text naturally guides the user to be "on" the
`psuh` branch when the patches are taken from it, we could even
shorten the command to

    ----
    $ git format-patch --cover-letter --base=auto -o psuh/ @{u}..
    ----

That extra shortening would need a bit more work in the earlier part
of [[format-patch]] section around the part that says "Luckily, this
is pretty simple".  Basically, we need to invent a plausible story
for the user to have done "git checkout psuh" earlier, so that it is
clear to the readers that the `psuh` branch is the current branch.

So it probably is a good idea to leave it outside the scope of this
topic.