| Message ID | 20211015122515.47535-1-bagasdotme@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] Documentation: specify base point when generating MyFirstContribution patchset | expand |
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].
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.
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.
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
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(+) base-commit: 2bd2f258f4195ac54293a3f45b86457c0bd5fc11