{"thread":{"id":"46484","subject":"[PATCH 1/2] doc: fix small issues in SubmittingPatches","startedAt":"2017-07-30T11:09:04Z","lastAt":"2017-08-07T14:34:25Z","messageCount":23,"participants":["Kaartic Sivaraam","Philip Oakley","Stefan Beller","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"325269","messageId":"20170730110921.11805-1-kaarticsivaraam91196@gmail.com","threadId":"46484","inReplyTo":null,"subject":"[PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-30T11:09:20Z","receivedAt":"2017-07-30T11:09:04Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Signed-off-by: Kaartic Sivaraam \n---\n Documentation/SubmittingPatches | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 558d465b6..9d0dab08d 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -293,7 +293,7 @@ then you just add a line saying\n \n Signed-off-by: Random J Developer \n \n-This line can be automatically added by Git if you run the git-commit\n+This line can be automatically added by Git if you run the 'git commit'\n command with the -s option.\n \n Notice that you can place your own Signed-off-by: line when\n@@ -366,7 +366,7 @@ suggests to the contributors:\n spend their time to improve your patch. Go back to step (2).\n \n (4) The list forms consensus that the last round of your patch is\n- good. Send it to the maintainer and cc the list.\n+ good. Send it to the maintainer and cc the list.\n \n (5) A topic branch is created with the patch and is merged to 'next',\n and cooked further and eventually graduates to 'master'.\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325270","messageId":"20170730110921.11805-2-kaarticsivaraam91196@gmail.com","threadId":"46484","inReplyTo":"20170730110921.11805-1-kaarticsivaraam91196@gmail.com","subject":"[PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-30T11:09:21Z","receivedAt":"2017-07-30T11:09:08Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Signed-off-by: Kaartic Sivaraam \n---\n I'm not sure if the first one (pull --rebase) is still\n required and hence leaving it as such. Let me know if it\n could be removed.\n\n Documentation/SubmittingPatches | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 9d0dab08d..a800e54a7 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -386,6 +386,10 @@ Know the status of your patch after submission\n tell you if your patch is merged in pu if you rebase on top of\n master).\n \n+* If you made your change in a separate branch () you can use\n+ 'git cherry master ' to see if the change has been merged\n+ into master.\n+\n * Read the Git mailing list, the maintainer regularly posts messages\n entitled \"What's cooking in git.git\" and \"What's in git.git\" giving\n the status of various proposed changes.\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325277","messageId":"8256C530C7DE43D7BC72BFB327DF4726@PhilipOakley","threadId":"46484","inReplyTo":"20170730110921.11805-1-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2017-07-30T14:49:21Z","receivedAt":"2017-07-30T14:49:26Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Kaartic Sivaraam\" \n\nminor nit: It's nice, for these single character changes, to give a clue in \nthe commit message as to what to look for.\n\nE.g.\n\nQuote the command, and remove duplicated space character\n\n--\nPhilip.\n\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> Documentation/SubmittingPatches | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/SubmittingPatches \n> b/Documentation/SubmittingPatches\n> index 558d465b6..9d0dab08d 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -293,7 +293,7 @@ then you just add a line saying\n>\n> Signed-off-by: Random J Developer \n>\n> -This line can be automatically added by Git if you run the git-commit\n> +This line can be automatically added by Git if you run the 'git commit'\n> command with the -s option.\n>\n> Notice that you can place your own Signed-off-by: line when\n> @@ -366,7 +366,7 @@ suggests to the contributors:\n> spend their time to improve your patch. Go back to step (2).\n>\n> (4) The list forms consensus that the last round of your patch is\n> - good. Send it to the maintainer and cc the list.\n> + good. Send it to the maintainer and cc the list.\n>\n> (5) A topic branch is created with the patch and is merged to 'next',\n> and cooked further and eventually graduates to 'master'.\n> -- \n> 2.14.0.rc1.434.g6eded367a\n> \n\n"},{"id":"325280","messageId":"1501431431.31112.9.camel@gmail.com","threadId":"46484","inReplyTo":"8256C530C7DE43D7BC72BFB327DF4726@PhilipOakley","subject":"Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-30T16:17:11Z","receivedAt":"2017-07-30T16:16:52Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Sun, 2017-07-30 at 15:49 +0100, Philip Oakley wrote:\n> From: \"Kaartic Sivaraam\" \n> \n> minor nit: It's nice, for these single character changes, to give a clue in \n> the commit message as to what to look for.\n> \n> E.g.\n> \n> Quote the command, and remove duplicated space character\n> \nFixed it. Will remember this in future. :)\n\n-- \nKaartic\n"},{"id":"325281","messageId":"20170730161816.2412-1-kaarticsivaraam91196@gmail.com","threadId":"46484","inReplyTo":"8256C530C7DE43D7BC72BFB327DF4726@PhilipOakley","subject":"[PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-30T16:18:16Z","receivedAt":"2017-07-30T16:18:15Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Replace the dashed version of a command with undashed\nversion and quote it.\n\nFurther, remove duplicated space character.\n\nSigned-off-by: Kaartic Sivaraam \n---\n Documentation/SubmittingPatches | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 558d465b6..9d0dab08d 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -293,7 +293,7 @@ then you just add a line saying\n \n Signed-off-by: Random J Developer \n \n-This line can be automatically added by Git if you run the git-commit\n+This line can be automatically added by Git if you run the 'git commit'\n command with the -s option.\n \n Notice that you can place your own Signed-off-by: line when\n@@ -366,7 +366,7 @@ suggests to the contributors:\n spend their time to improve your patch. Go back to step (2).\n \n (4) The list forms consensus that the last round of your patch is\n- good. Send it to the maintainer and cc the list.\n+ good. Send it to the maintainer and cc the list.\n \n (5) A topic branch is created with the patch and is merged to 'next',\n and cooked further and eventually graduates to 'master'.\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325314","messageId":"CAGZ79kYg9jQ3kaKnNEJCH9fde=ar1KPiUr7=X+TguNc0Twqdzg@mail.gmail.com","threadId":"46484","inReplyTo":"20170730161816.2412-1-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-31T20:23:23Z","receivedAt":"2017-07-31T20:23:30Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Sun, Jul 30, 2017 at 9:18 AM, Kaartic Sivaraam\n wrote:\n> Replace the dashed version of a command with undashed\n> version and quote it.\n\nI like it, but similar as below, we'd want to go for\nconsistency.\n\n>\n> Further, remove duplicated space character.\n\nhttps://en.wikipedia.org/wiki/Sentence_spacing\nseems like a globally controversial thing. (I assumed\nit was some sort of local dialect before researching\nit properly)\n\nI personally do not mind one way or another regarding\n(double) spaces after a period, but I would think we'd\nstrive for consistency throughout the project.\n\n>\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> Documentation/SubmittingPatches | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index 558d465b6..9d0dab08d 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -293,7 +293,7 @@ then you just add a line saying\n>\n> Signed-off-by: Random J Developer \n>\n> -This line can be automatically added by Git if you run the git-commit\n> +This line can be automatically added by Git if you run the 'git commit'\n> command with the -s option.\n>\n> Notice that you can place your own Signed-off-by: line when\n> @@ -366,7 +366,7 @@ suggests to the contributors:\n> spend their time to improve your patch. Go back to step (2).\n>\n> (4) The list forms consensus that the last round of your patch is\n> - good. Send it to the maintainer and cc the list.\n> + good. Send it to the maintainer and cc the list.\n>\n> (5) A topic branch is created with the patch and is merged to 'next',\n> and cooked further and eventually graduates to 'master'.\n> --\n> 2.14.0.rc1.434.g6eded367a\n>\n"},{"id":"325318","messageId":"xmqq8tj4ibvj.fsf@gitster.mtv.corp.google.com","threadId":"46484","inReplyTo":"CAGZ79kYg9jQ3kaKnNEJCH9fde=ar1KPiUr7=X+TguNc0Twqdzg@mail.gmail.com","subject":"Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-31T20:34:40Z","receivedAt":"2017-07-31T20:34:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n>> Further, remove duplicated space character.\n>\n> https://en.wikipedia.org/wiki/Sentence_spacing\n> seems like a globally controversial thing. (I assumed\n> it was some sort of local dialect before researching\n> it properly)\n>\n> I personally do not mind one way or another regarding\n> (double) spaces after a period, but I would think we'd\n> strive for consistency throughout the project.\n\nI am not sure if that is something we want to encourage newbies to\nbe doing. Especially a patch like this (notice the double-space\nbefore \"Go back to...\" in the pre-context) makes me feel it is\ndistracting without adding much \"consistency\" value.\n\nAnd no, I am not suggesting a tree-wide sweep to make everything\nconsistent.\n\n>> spend their time to improve your patch. Go back to step (2).\n>>\n>> (4) The list forms consensus that the last round of your patch is\n>> - good. Send it to the maintainer and cc the list.\n>> + good. Send it to the maintainer and cc the list.\n>>\n>> (5) A topic branch is created with the patch and is merged to 'next',\n>> and cooked further and eventually graduates to 'master'.\n>> --\n>> 2.14.0.rc1.434.g6eded367a\n>>\n"},{"id":"325374","messageId":"1501603171.1671.8.camel@gmail.com","threadId":"46484","inReplyTo":"CAGZ79kYg9jQ3kaKnNEJCH9fde=ar1KPiUr7=X+TguNc0Twqdzg@mail.gmail.com","subject":"Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-01T15:59:31Z","receivedAt":"2017-08-01T16:01:00Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Mon, 2017-07-31 at 13:23 -0700, Stefan Beller wrote:\n> On Sun, Jul 30, 2017 at 9:18 AM, Kaartic Sivaraam\n> wrote:\n> > Replace the dashed version of a command with undashed\n> > version and quote it.\n> \n> I like it, but similar as below, we'd want to go for\n> consistency.\n> \nI assume you mean the consistency in quoting i.e., you're expecting the\npatch to use (\") instead of (') for quoting. Correct me, if I'm wrong.\n\n> > \n> > Further, remove duplicated space character.\n> \n> https://en.wikipedia.org/wiki/Sentence_spacing\n> seems like a globally controversial thing. (I assumed\n> it was some sort of local dialect before researching\n> it properly)\n> \nMan, I had no idea about people using two spaces after period.\n\n> I personally do not mind one way or another regarding\n> (double) spaces after a period, but I would think we'd\n> strive for consistency throughout the project.\n> \nConsistency is crucial. I'll just remove that part of the patch.\n\n-- \nKaartic\n"},{"id":"325376","messageId":"20170801160539.5587-1-kaarticsivaraam91196@gmail.com","threadId":"46484","inReplyTo":"CAGZ79kYg9jQ3kaKnNEJCH9fde=ar1KPiUr7=X+TguNc0Twqdzg@mail.gmail.com","subject":"[PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-01T16:05:38Z","receivedAt":"2017-08-01T16:05:47Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Replace the dashed version of a command with undashed\nversion and quote it.\n\nUse double quotes to quote a git command for consistency.\n\nSigned-off-by: Kaartic Sivaraam \n---\n Documentation/SubmittingPatches | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 558d465b6..886fe3650 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -293,7 +293,7 @@ then you just add a line saying\n \n Signed-off-by: Random J Developer \n \n-This line can be automatically added by Git if you run the git-commit\n+This line can be automatically added by Git if you run the \"git commit\"\n command with the -s option.\n \n Notice that you can place your own Signed-off-by: line when\n@@ -380,7 +380,7 @@ their trees themselves.\n Know the status of your patch after submission\n \n * You can use Git itself to find out when your patch is merged in\n- master. 'git pull --rebase' will automatically skip already-applied\n+ master. \"git pull --rebase\" will automatically skip already-applied\n patches, and will let you know. This works only if you rebase on top\n of the branch in which your patch has been merged (i.e. it will not\n tell you if your patch is merged in pu if you rebase on top of\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325377","messageId":"20170801160539.5587-2-kaarticsivaraam91196@gmail.com","threadId":"46484","inReplyTo":"20170801160539.5587-1-kaarticsivaraam91196@gmail.com","subject":"[PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-01T16:05:39Z","receivedAt":"2017-08-01T16:06:03Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Signed-off-by: Kaartic Sivaraam \n---\n Documentation/SubmittingPatches | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 886fe3650..7197709ee 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -386,6 +386,10 @@ Know the status of your patch after submission\n tell you if your patch is merged in pu if you rebase on top of\n master).\n \n+* If you made your change in a separate branch () you can use\n+ \"git cherry master \" to see if the change has been merged\n+ into master.\n+\n * Read the Git mailing list, the maintainer regularly posts messages\n entitled \"What's cooking in git.git\" and \"What's in git.git\" giving\n the status of various proposed changes.\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325382","messageId":"CAGZ79kY_NdBe1QjJWrLUkfDOk8Zrnopa945F1xBq=WFDNpRWMg@mail.gmail.com","threadId":"46484","inReplyTo":"1501603171.1671.8.camel@gmail.com","subject":"Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-01T17:38:55Z","receivedAt":"2017-08-01T17:39:02Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam\n wrote:\n> On Mon, 2017-07-31 at 13:23 -0700, Stefan Beller wrote:\n>> On Sun, Jul 30, 2017 at 9:18 AM, Kaartic Sivaraam\n>> wrote:\n>> > Replace the dashed version of a command with undashed\n>> > version and quote it.\n>>\n>> I like it, but similar as below, we'd want to go for\n>> consistency.\n>>\n> I assume you mean the consistency in quoting i.e., you're expecting the\n> patch to use (\") instead of (') for quoting. Correct me, if I'm wrong.\n\nActually I did not imply any expectation on the outcome, because I\ndo not know what the consistency end game looks like for this issue.\n\nSo maybe we'd want to go with the currently most used way?\n(Are there only three? (a) with dash, (b) with single quotes and\n(c) with double quotes?)\n\n>> >\n>> > Further, remove duplicated space character.\n>>\n>> https://en.wikipedia.org/wiki/Sentence_spacing\n>> seems like a globally controversial thing. (I assumed\n>> it was some sort of local dialect before researching\n>> it properly)\n>>\n> Man, I had no idea about people using two spaces after period.\n>\n>> I personally do not mind one way or another regarding\n>> (double) spaces after a period, but I would think we'd\n>> strive for consistency throughout the project.\n>>\n> Consistency is crucial. I'll just remove that part of the patch.\n>\n> --\n> Kaartic\n"},{"id":"325384","messageId":"CAGZ79kZgV1=2HcYeXyoCy2Jk6v__trvTh_-rH+kbFX7fgWziyw@mail.gmail.com","threadId":"46484","inReplyTo":"20170801160539.5587-2-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-01T17:46:11Z","receivedAt":"2017-08-01T17:46:18Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 1, 2017 at 9:05 AM, Kaartic Sivaraam\n wrote:\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> Documentation/SubmittingPatches | 4 ++++\n> 1 file changed, 4 insertions(+)\n>\n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index 886fe3650..7197709ee 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -386,6 +386,10 @@ Know the status of your patch after submission\n> tell you if your patch is merged in pu if you rebase on top of\n> master).\n>\n> +* If you made your change in a separate branch () you can use\n> + \"git cherry master \" to see if the change has been merged\n> + into master.\n> +\n> * Read the Git mailing list, the maintainer regularly posts messages\n> entitled \"What's cooking in git.git\" and \"What's in git.git\" giving\n> the status of various proposed changes.\n\nActually I am slightly negative on this one, because of\noccurrences like [1].\n\nOur SubmittingPatches is already considered *too long* for most people\nwho just want to drop a drive-by patch.\n\nAdding more knowledge (which btw is about general git usage and not\nspecific to our development workflow; you'd find the same tip in the\nkernel community).\n\nI wonder if we need a document that describes workflows.\n(Oh, look we have 'man gitworkflows'! I did not know)\n\nSo maybe we want to cut a lot of workflow related commendatory from\nthe SubmitingPatches and then encourage to read such man page?\n\n[1 ]https://public-inbox.org/git/CA+dzEB=cDvp7ZS8x+p+U-5NbK3SNd0FPyj_wP=gvi8mJi6D2ag@mail.gmail.com/\n\n\n\n> --\n> 2.14.0.rc1.434.g6eded367a\n>\n"},{"id":"325407","messageId":"C89BA7B590AA460BB298258BA85E8619@PhilipOakley","threadId":"46484","inReplyTo":"CAGZ79kYg9jQ3kaKnNEJCH9fde=ar1KPiUr7=X+TguNc0Twqdzg@mail.gmail.com","subject":"Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2017-08-01T21:04:57Z","receivedAt":"2017-08-01T21:05:07Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Stefan Beller\" \n>> Further, remove duplicated space character.\n>\n> https://en.wikipedia.org/wiki/Sentence_spacing\n> seems like a globally controversial thing. (I assumed\n> it was some sort of local dialect before researching\n> it properly)\n>\n> I personally do not mind one way or another regarding\n> (double) spaces after a period, but I would think we'd\n> strive for consistency throughout the project.\n>\n\nThe use of double spaces was a taught typing technique as recently as the \nearly-mid 1980s when my wife did a UK university postgraduate secretarial \ncourse. This was just before PC word processing took off. It takes a long \nwhile for the old ways to die off!\n--\nPhilip \n\n"},{"id":"325428","messageId":"1501676577.1957.4.camel@gmail.com","threadId":"46484","inReplyTo":"CAGZ79kY_NdBe1QjJWrLUkfDOk8Zrnopa945F1xBq=WFDNpRWMg@mail.gmail.com","subject":"Re: [RFC] The correct and consistent alternative to quote a command ?","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-02T12:22:57Z","receivedAt":"2017-08-02T12:22:30Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Tue, 2017-08-01 at 10:38 -0700, Stefan Beller wrote:\n> On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam wrote:\n> > I assume you mean the consistency in quoting i.e., you're expecting the\n> > patch to use (\") instead of (') for quoting. Correct me, if I'm wrong.\n> \n> Actually I did not imply any expectation on the outcome, because I\n> do not know what the consistency end game looks like for this issue.\n> \n> So maybe we'd want to go with the currently most used way?\nOn scanning through Documentation/SubmittingPatches, I saw that most of\nthe commands were quoted using double quotes and chose to use it for\nthis patch. I'm not sure if it's the right one to use.\n\nChanging the subject of this mail; hoping some one who has thoughts\nabout this would dive-in.\n\n> (Are there only three? (a) with dash, (b) with single quotes and\n> (c) with double quotes?)\n\n-- \nKaartic\n"},{"id":"325429","messageId":"1501677122.1957.8.camel@gmail.com","threadId":"46484","inReplyTo":"CAGZ79kZgV1=2HcYeXyoCy2Jk6v__trvTh_-rH+kbFX7fgWziyw@mail.gmail.com","subject":"Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-02T12:32:02Z","receivedAt":"2017-08-02T12:31:39Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote:\n> Actually I am slightly negative on this one, because of\n> occurrences like [1].\n> \n> Our SubmittingPatches is already considered *too long* for most people\n> who just want to drop a drive-by patch.\n> \n> Adding more knowledge (which btw is about general git usage and not\n> specific to our development workflow; you'd find the same tip in the\n> kernel community).\n> \n> I wonder if we need a document that describes workflows.\n> (Oh, look we have 'man gitworkflows'! I did not know)\n> \n> So maybe we want to cut a lot of workflow related commendatory from\n> the SubmitingPatches and then encourage to read such man page?\n> \nThat's right. Maybe Documentation/SubmittingPatches needs a revamp to\nbe one-time contributor friendly? Maybe introducing a \"gist\" for people\nwho do not have the time to read the whole document, might be of help?\n\n> [1 ]https://public-inbox.org/git/CA+dzEB=cDvp7ZS8x+p+U-5NbK3SNd0FPyj_wP=gvi8mJi6D2ag@mail.gmail.com/\n> \n> \n> \n> > --\n> > 2.14.0.rc1.434.g6eded367a\n> > \n\n-- \nKaartic\n"},{"id":"325433","messageId":"xmqqo9rydlqr.fsf@gitster.mtv.corp.google.com","threadId":"46484","inReplyTo":"1501676577.1957.4.camel@gmail.com","subject":"Re: [RFC] The correct and consistent alternative to quote a command ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-02T15:37:16Z","receivedAt":"2017-08-02T15:37:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> On Tue, 2017-08-01 at 10:38 -0700, Stefan Beller wrote:\n>> On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam wrote:\n>> > I assume you mean the consistency in quoting i.e., you're expecting the\n>> > patch to use (\") instead of (') for quoting. Correct me, if I'm wrong.\n>> \n>> Actually I did not imply any expectation on the outcome, because I\n>> do not know what the consistency end game looks like for this issue.\n>> \n>> So maybe we'd want to go with the currently most used way?\n> On scanning through Documentation/SubmittingPatches, I saw that most of\n> the commands were quoted using double quotes and chose to use it for\n> this patch. I'm not sure if it's the right one to use.\n\nAfter reading the patch before seeing the above, I also came to the\nconclusion that the above is exactly what you are aiming at, and I\nthought that was a reasonable thing to do.\n\n"},{"id":"325436","messageId":"xmqqini6dkmu.fsf@gitster.mtv.corp.google.com","threadId":"46484","inReplyTo":"1501677122.1957.8.camel@gmail.com","subject":"Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-02T16:01:13Z","receivedAt":"2017-08-02T16:01:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote:\n>> Actually I am slightly negative on this one, because of\n>> occurrences like [1].\n>> \n>> Our SubmittingPatches is already considered *too long* for most people\n>> who just want to drop a drive-by patch.\n>> \n>> Adding more knowledge (which btw is about general git usage and not\n>> specific to our development workflow; you'd find the same tip in the\n>> kernel community).\n>> \n>> I wonder if we need a document that describes workflows.\n>> (Oh, look we have 'man gitworkflows'! I did not know)\n>> \n>> So maybe we want to cut a lot of workflow related commendatory from\n>> the SubmitingPatches and then encourage to read such man page?\n>> \n> That's right. Maybe Documentation/SubmittingPatches needs a revamp to\n> be one-time contributor friendly? Maybe introducing a \"gist\" for people\n> who do not have the time to read the whole document, might be of help?\n\nFirst of all, I do not think lack of one-time contributor is\nsomething we should consider to be a problem. Supporting new\ncontributors so that they will be involved more in the development\nprocess is a lot more important issue.\n\nA new contributor will get something wrong no matter what the\ndocumentation says. One-time contributor's intention is \"I am\nsending a patch this time, but I have no plan to get involved\nfurther---I do not have time for this\". It ridiculous to ask for a\npatch that adds an 's' to the end of a third-party-singular verb in\nthe present tense to be rerolled only because the title had an extra\nfull-stop at the end. Practically, a patch like that by a \"one time\ncontributor\" will always have to be fixed before committing it.\n\nI think the exchange Stefan cited was an example that we want to\nhave more of. The contributor is indicating that, even though the\npatch could be a drive-by patch by one-timer from whom we will never\nhear again, it is not--the contributor is willing to learn the way\nthings are done here, and showing that it is worth _our_ time to\nexplain the things so that the future patches will take less effort\nto accept on our side.\n\nBecause we do not have a group of dedicated volunteers, it is done\nby more experienced people around here but that can be done only\nwhen they have time. I view it as a more severe problem than any\ndocumentation. An abbreviated version of the documentation to\ninvite more new people means that we must be prepared to give more\nhigh-touch onboarding help to them.\n\n\n\n\n"},{"id":"325439","messageId":"xmqq60e6djcu.fsf@gitster.mtv.corp.google.com","threadId":"46484","inReplyTo":"xmqqini6dkmu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-02T16:28:49Z","receivedAt":"2017-08-02T16:28:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I think the exchange Stefan cited was an example that we want to\n> have more of. The contributor is indicating that, even though the\n> patch could be a drive-by patch by one-timer from whom we will never\n> hear again, it is not--the contributor is willing to learn the way\n> things are done here, and showing that it is worth _our_ time to\n> explain the things so that the future patches will take less effort\n> to accept on our side.\n>\n> Because we do not have a group of dedicated volunteers, it is done\n> by more experienced people around here but that can be done only\n> when they have time. I view it as a more severe problem than any\n> documentation. An abbreviated version of the documentation to\n> invite more new people means that we must be prepared to give more\n> high-touch onboarding help to them.\n\nJust to make sure there is no misunderstanding, I am not saying \"do\nnot update the doc to have an abbreviated version, because we will\nget more clueless newbies\". I am saying that it is not a good idea\nto add an abbreviated version _before_ we are prepared to handle\nmore patches from new people that require high-touch help.\n\nIf you are volunteering to coordinate and form the onboarding\nhelpers group, that would be great.\n\nThanks.\n"},{"id":"325445","messageId":"CAGZ79kbCg+xdVE1U0dv8MJ6vUuWvraWQCMSzKOTBsOvtdSvkGg@mail.gmail.com","threadId":"46484","inReplyTo":"1501676577.1957.4.camel@gmail.com","subject":"Re: [RFC] The correct and consistent alternative to quote a command ?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-02T17:32:27Z","receivedAt":"2017-08-02T17:32:35Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Aug 2, 2017 at 5:22 AM, Kaartic Sivaraam\n wrote:\n> On Tue, 2017-08-01 at 10:38 -0700, Stefan Beller wrote:\n>> On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam wrote:\n>> > I assume you mean the consistency in quoting i.e., you're expecting the\n>> > patch to use (\") instead of (') for quoting. Correct me, if I'm wrong.\n>>\n>> Actually I did not imply any expectation on the outcome, because I\n>> do not know what the consistency end game looks like for this issue.\n>>\n>> So maybe we'd want to go with the currently most used way?\n> On scanning through Documentation/SubmittingPatches, I saw that most of\n> the commands were quoted using double quotes and chose to use it for\n> this patch. I'm not sure if it's the right one to use.\n\nThanks for checking. I think it is a reasonable thing to do then.\n\n>\n> Changing the subject of this mail; hoping some one who has thoughts\n> about this would dive-in.\n>\n>> (Are there only three? (a) with dash, (b) with single quotes and\n>> (c) with double quotes?)\n>\n> --\n> Kaartic\n"},{"id":"325450","messageId":"CAGZ79kYArf6R-vx1-Lm4X_ANLMrXc3VNd2aCQMnqq3J6y-s31Q@mail.gmail.com","threadId":"46484","inReplyTo":"xmqq60e6djcu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-02T17:58:18Z","receivedAt":"2017-08-02T17:58:29Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Aug 2, 2017 at 9:28 AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> I think the exchange Stefan cited was an example that we want to\n>> have more of. The contributor is indicating that, even though the\n>> patch could be a drive-by patch by one-timer from whom we will never\n>> hear again, it is not--the contributor is willing to learn the way\n>> things are done here, and showing that it is worth _our_ time to\n>> explain the things so that the future patches will take less effort\n>> to accept on our side.\n\nThe example I cited contains two important parts that I considered.\n\n> I tried to follow as best I could, here's my attempt (please advise).\n\n ok, I can help out as that conversation is very likely\n to deliver some impact.\n\n> I'm a bit overwhelmed by the documentation for submitting a patch!\n\n That may be either a contributors problem (lacking time or\n motivation to go through a long document) or a problem with\n the community.\n\nHere are my thoughts on the \"problem with the community\":\n\n We are using Git ourselves as a mere (content-)version-control-system\n What we really need is a community oriented workflow tool:\n Instead of writing a long-winded document on what you can\n do wrong in each contribution, we should have technical solutions\n that just present the single issue that needs addressing.\n\n For example when a contributor forgets to sign-off a patch,\n git-send-email could warn about the missing sign-off and\n present the rationale why our community needs sign-offs.\n\n As this is specific to our community, such that it cannot be\n baked into git-send-email, but rather we'd need a distributed\n configuration that is respected by various git commands.\n\nWe had the discussion on shipping a project config which is\nrespected by git commands lately when discussing the\n.gitorder file that I proposed, and IIRC such a thing \"doesn't\nquite fit into the broad picture of a version control system\",\nso maybe we need another tooling in our community?\n\n Another example would be to show a hint/advice when\n commits with no or very short commit message are created.\n (also this is project specific, other communities do not expect\n commit messages as we do. So they would not want to utilize\n such an advice given).\n\n>>\n>> Because we do not have a group of dedicated volunteers, it is done\n>> by more experienced people around here but that can be done only\n>> when they have time. I view it as a more severe problem than any\n>> documentation. An abbreviated version of the documentation to\n>> invite more new people means that we must be prepared to give more\n>> high-touch onboarding help to them.\n>\n> Just to make sure there is no misunderstanding, I am not saying \"do\n> not update the doc to have an abbreviated version, because we will\n> get more clueless newbies\". I am saying that it is not a good idea\n> to add an abbreviated version _before_ we are prepared to handle\n> more patches from new people that require high-touch help.\n>\n> If you are volunteering to coordinate and form the onboarding\n> helpers group, that would be great.\n\nI would not want to explain the same thing over and over again,\nbut rather have a technical solution that explains the problem and\nsolution once it is detected.\n\nComing up with a technical solution for each little quirk\nis not the hard part (e.g. grep for the sign off string, count lines of\nthe commit message), but rather to put it in place. (How can I make\nsure that contributors run these small checker scripts?\nCurrently I cannot.)\n\nThanks.\n"},{"id":"325546","messageId":"1501774553.9604.1.camel@gmail.com","threadId":"46484","inReplyTo":"CAGZ79kbCg+xdVE1U0dv8MJ6vUuWvraWQCMSzKOTBsOvtdSvkGg@mail.gmail.com","subject":"Re: [RFC] The correct and consistent alternative to quote a command ?","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-03T15:35:53Z","receivedAt":"2017-08-03T15:35:33Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wed, 2017-08-02 at 10:32 -0700, Stefan Beller wrote:\n> Thanks for checking.\nYou're welcome. :)\n\n-- \nKaartic\n"},{"id":"325683","messageId":"1502116408.3172.3.camel@gmail.com","threadId":"46484","inReplyTo":"xmqqini6dkmu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-07T14:33:28Z","receivedAt":"2017-08-07T14:33:07Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wed, 2017-08-02 at 09:01 -0700, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n> > On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote:\n> > > So maybe we want to cut a lot of workflow related commendatory from\n> > > the SubmitingPatches and then encourage to read such man page?\n> > > \n> > \n> > That's right. Maybe Documentation/SubmittingPatches needs a revamp to\n> > be one-time contributor friendly? Maybe introducing a \"gist\" for people\n> > who do not have the time to read the whole document, might be of help?\n> \n> First of all, I do not think lack of one-time contributor is\n> something we should consider to be a problem. Supporting new\n> contributors so that they will be involved more in the development\n> process is a lot more important issue.\n> \nFirst of all, I would like to clear a little mis-interpretation here.\nThough I used the phrase 'one-time contributor', I didn't want a gist\nthat targets only *those* people. I was thinking, in general, about\npeople who would like to contribute but find the documentation\noverwhelming (an example might be the thread pointed out by Stefan). In\nwhich case, they would want to check if their patch meets the *basic\ncriterias* and send it to the community hoping it would be accepted\nwith at least 75% probability.\n\nI'll send a patch that tries to make 'Documentation/SubmittingPatches'\nless overwhelming without losing much of it's content, some time soon.\n\n> I think the exchange Stefan cited was an example that we want to\n> have more of. The contributor is indicating that, even though the\n> patch could be a drive-by patch by one-timer from whom we will never\n> hear again, it is not--the contributor is willing to learn the way\n> things are done here, and showing that it is worth _our_ time to\n> explain the things so that the future patches will take less effort\n> to accept on our side.\n> \nI thought a *good* 'gist' would obviate that kind of effort. Let's see\nif I could come up with something.\n\n> Because we do not have a group of dedicated volunteers, it is done\n> by more experienced people around here but that can be done only\n> when they have time. I view it as a more severe problem than any\n> documentation. An abbreviated version of the documentation to\n> invite more new people means that we must be prepared to give more\n> high-touch onboarding help to them.\n> \nI think an abbrievated documentation whilst inviting new people\n*should* obviate the onboarding help, saving everyone's time (win-win).\n\n-- \nKaartic\n\n"},{"id":"325684","messageId":"1502116490.3172.6.camel@gmail.com","threadId":"46484","inReplyTo":"CAGZ79kYArf6R-vx1-Lm4X_ANLMrXc3VNd2aCQMnqq3J6y-s31Q@mail.gmail.com","subject":"Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-07T14:34:50Z","receivedAt":"2017-08-07T14:34:25Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wed, 2017-08-02 at 10:58 -0700, Stefan Beller wrote:\n> That may be either a contributors problem (lacking time or\n> motivation to go through a long document) or a problem with\n> the community.\n> \nI'm trying to avoid the former.\n\n> I would not want to explain the same thing over and over again,\n> but rather have a technical solution that explains the problem and\n> solution once it is detected.\n> \n> Coming up with a technical solution for each little quirk\n> is not the hard part (e.g. grep for the sign off string, count lines of\n> the commit message), but rather to put it in place. (How can I make\n> sure that contributors run these small checker scripts?\n> Currently I cannot.)\n> \nI could see quite some alternatives for this.\n\n1. scripts\n\n I guess the kernel community use some scripts to check if the patch\n has the required style.[ref 1][ref 2]. I guess we could do something\n similar. Like writing a script that checks the log messages for the\n required format (sign-off, area etc.) and giving users advice about\n how to fix the issue. After a all script test pass we could give\n some advice to the user about how the patch needs to be sent.\n\n To identify the set of commit messages that need to be checked we\n could make the script accept a single parameter that specifies the\n base of the branch. I'm not sure if this part could be automated.\n\n2. Hooks\n\n warning: this might be a little over thought.\n\n 1. Code all the checks as 'hooks scripts' that aren't samples.\n Possibly scripts related to 'commit-msg'.\n\n 2. Place them in a 'hooks' directory under a new directory, possibly\n named 'hook-checks'.\n\n 3. Inform the new contributor to re-initialize his git.git with\n\n $ git init --template=/path/to/git/hook-checks\n\n 4. Rebasing their commits with 'rewording' each\n\n Of course, this relies on the fact that he wouldn't have enabled\n hooks in their git.git. In which case he would have to merge the\n scripts with his own scripts.\n\nI'm not pretty sure if they're feasible or not.\n\n-- \nKaartic\n"}]}