Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged
flat view
From: Stefan Beller <hidden>
Date: 2017-08-01 17:46:18
On Tue, Aug 1, 2017 at 9:05 AM, Kaartic Sivaraam [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Signed-off-by: Kaartic Sivaraam <redacted> --- 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