On Tue, Aug 1, 2017 at 9:05 AM, Kaartic Sivaraam <kaarticsivaraam91196@xxxxxxxxx> wrote: > Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@xxxxxxxxx> > --- > 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@xxxxxxxxxxxxxx/ > -- > 2.14.0.rc1.434.g6eded367a >
