Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

From: Stefan Beller <sbeller@google.com>
Date: Aug 1, 2017, 17:46 UTC
Message-ID: <CAGZ79kZgV1=2HcYeXyoCy2Jk6v__trvTh_-rH+kbFX7fgWziyw@mail.gmail.com>
In-Reply-To: <20170801160539.5587-2-kaarticsivaraam91196@gmail.com>

On Tue, Aug 1, 2017 at 9:05 AM, Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> wrote:

Show 20 quoted lines

> Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
> ---
>  Documentation/SubmittingPatches | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 886fe3650..7197709ee 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -386,6 +386,10 @@ Know the status of your patch after submission
>    tell you if your patch is merged in pu if you rebase on top of
>    master).
>
> +* If you made your change in a separate branch (<branch>) you can use
> +  "git cherry master <branch>" to see if the change has been merged
> +  into master.
> +
>  * Read the Git mailing list, the maintainer regularly posts messages
>    entitled "What's cooking in git.git" and "What's in git.git" giving
>    the status of various proposed changes.

Actually I am slightly negative on this one, because of occurrences like [1].

Our SubmittingPatches is already considered *too long* for most people who just want to drop a drive-by patch.

Adding more knowledge (which btw is about general git usage and not specific to our development workflow; you'd find the same tip in the kernel community).

I wonder if we need a document that describes workflows. (Oh, look we have 'man gitworkflows'! I did not know)

So maybe we want to cut a lot of workflow related commendatory from the SubmitingPatches and then encourage to read such man page?

[1 ]https://public-inbox.org/git/CA+dzEB=cDvp7ZS8x+p+U-5NbK3SNd0FPyj_wP=gvi8mJi6D2ag@mail.gmail.com/

> --
> 2.14.0.rc1.434.g6eded367a
>