{"thread":{"id":"34456","subject":"maintainer question: config http..* patch administrivia","startedAt":"2013-07-17T15:02:33Z","lastAt":"2013-07-17T18:15:53Z","messageCount":3,"participants":["Kyle J. McKay","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"223586","messageId":"68EA6AFC-D90D-4704-AF1A-92AF15617E23@gmail.com","threadId":"34456","inReplyTo":null,"subject":"maintainer question: config http..* patch administrivia","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2013-07-17T15:02:33Z","receivedAt":"2013-07-17T15:02:33Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"I have pondered these items:\n\nOn Jul 12, 2013, at 11:48, Junio C Hamano wrote:\n> Perhaps we should fix it as a preparatory patch (1/2) before the\n> main \"feature addition\" patch.\n\n\nOn Jul 12, 2013, at 11:52, Junio C Hamano wrote:\n> Subject: [PATCH] http.c: fix parsing of \n> http.sslCertPasswordProtected variable\n\nOn Jul 14, 2013, at 21:02, Junio C Hamano wrote:\n> Assuming that Aaron and Peff's enhancement will not be a backward\n> incompatible update, my preference is to take the posted matching\n> semantics as-is (you may have some other changes that does not\n> change the \"strictly textual match\" semantics).\n\nAnd in response I have previously sent out a combined v5 patch that has:\n\n0001: your preparatory http.sslCertPasswordProtected patch\n0002: logically related GIT_SSL_CERT_PASSWORD_PROTECTED patch\n0003: textual matching http..* patch\n0004: url normalization matching http..*\n0005: test for url normalization function\n\nHowever, upon further consideration (I noticed that the preparatory \npatch and v4 of the textual matching patch made their way into pu), \nperhaps it would be more convenient for you if I re-released the \nfollowing patch series:\n\n\n[PATCH v5]: config: support http..* settings - (1) textual matching\n\n* contains 0001 the same preparatory http.sslCertPasswordProtected\n* contains 0002 the same v5 textual matching http..* patch\n\n\n[PATCH v2]: config: support http..* settings - (2) url \nnormalization\n\n* contains 0001 url normalization matching with feedback updates\n* contains 0002 url normalization test\n\n\n[PATCH v1]: config: support http..* settings - (3) any user \nmatching\n\n* contains 0001 a new patch that extends (2) to include any user \nmatching\n\n\nAnd drop the GIT_SSL_CERT_PASSWORD_PROTECTED patch as while it's \nlogically related to the http.sslCertPasswordProtected patch it's not \nlogistically related since independent areas of the file are touched \nand it could be successfully applied before or after the other \npatches. It can go together with any forthcoming enable-only fix for \nGIT_SSL_CERT_PASSWORD_PROTECTED and other such environment variables \nor just be dropped entirely.\n\nI do not, however, wish to create any additional maintainer work, so \nwanted to check with you before sending out any of the reissues.\n"},{"id":"223597","messageId":"7v7ggp6qdf.fsf@alter.siamese.dyndns.org","threadId":"34456","inReplyTo":"68EA6AFC-D90D-4704-AF1A-92AF15617E23@gmail.com","subject":"Re: maintainer question: config http..* patch administrivia","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-17T17:35:56Z","receivedAt":"2013-07-17T17:35:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kyle J. McKay\" writes:\n\n> However, upon further consideration (I noticed that the preparatory\n> patch and v4 of the textual matching patch made their way into pu),\n\nDo not read too much into being in 'pu'. They are there primarily\nso that I won't forget what is in-flight and can be replaced or\ndropped.\n\n> perhaps it would be more convenient for you if I re-released the\n> following patch series:\n\nSorry, but I do not understand. What do you mean by having these\nthree patch series? Are they \"There are three possibilities, pick\none and discard the other two\"? If so, then as the maintainer, I\npersonally would not care ;-), as they would be commented upon, and\nI won't pick any of them up until there is one list favorite.\n\nIf \"These build on top of each other in this order\", then it is\neasier for me to manage if they were in a single series.\n\nIf f1ff763a (http.c: fix parsing of http.sslCertPasswordProtected\nvariable, 2013-07-12) is already solid and need no further tweaking,\nit would be wise not to include the patch in any of your reroll in\nany case. Instead, just build your series on top of that commit,\nand make it clear that the series is meant to apply on top of that\ncommit in the cover letter [0/n] of the series, or after \"---\" line\nof the first patch [1/n] in the series.\n\nAs to allowing GIT_SSL_CERT_PASSWORD_PROTECTED=no, I agree that it\ndoes not belong to the http.*. configuration series, so making\nit an independent patch, perhaps on top of f1ff763a, would make\nsense. If the other patches have any textual dependency, you can\nmake it [1/n] of your series and we can treat it just like f1ff763a,\nthat is, make sure it is solid regardless of the rest of the series,\nand make it advance before the remainder of the series, so that we\ncan still replace http.*. implementation on top of these two\nfreely.\n\n>\n> [PATCH v5]: config: support http..* settings - (1) textual matching\n>\n> * contains 0001 the same preparatory http.sslCertPasswordProtected\n> * contains 0002 the same v5 textual matching http..* patch\n>\n>\n> [PATCH v2]: config: support http..* settings - (2) url\n> normalization\n>\n> * contains 0001 url normalization matching with feedback updates\n> * contains 0002 url normalization test\n>\n>\n> [PATCH v1]: config: support http..* settings - (3) any user\n> matching\n>\n> * contains 0001 a new patch that extends (2) to include any user\n> matching\n>\n>\n> And drop the GIT_SSL_CERT_PASSWORD_PROTECTED patch as while it's\n> logically related to the http.sslCertPasswordProtected patch it's not\n> logistically related since independent areas of the file are touched\n> and it could be successfully applied before or after the other\n> patches. It can go together with any forthcoming enable-only fix for\n> GIT_SSL_CERT_PASSWORD_PROTECTED and other such environment variables\n> or just be dropped entirely.\n>\n> I do not, however, wish to create any additional maintainer work, so\n> wanted to check with you before sending out any of the reissues.\n"},{"id":"223600","messageId":"CCADBC71-B5F4-4D69-B359-AF45F15F2816@gmail.com","threadId":"34456","inReplyTo":"7v7ggp6qdf.fsf@alter.siamese.dyndns.org","subject":"Re: maintainer question: config http..* patch administrivia","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2013-07-17T18:15:53Z","receivedAt":"2013-07-17T18:15:53Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 17, 2013, at 10:35, Junio C Hamano wrote:\n> \"Kyle J. McKay\" writes:\n>\n>> perhaps it would be more convenient for you if I re-released the\n>> following patch series:\n>\n> If \"These build on top of each other in this order\", then it is\n> easier for me to manage if they were in a single series.\n\nYup. They build on one another so each requires the previous. Will \nkeep them in a single series.\n\n\n> If f1ff763a (http.c: fix parsing of http.sslCertPasswordProtected\n> variable, 2013-07-12) is already solid and need no further tweaking,\n> it would be wise not to include the patch in any of your reroll in\n> any case. Instead, just build your series on top of that commit,\n> and make it clear that the series is meant to apply on top of that\n> commit in the cover letter [0/n] of the series, or after \"---\" line\n> of the first patch [1/n] in the series.\n\nGot it. Will do. f1ff763a looks solid to me:\n\nReviewed-by: Kyle J. McKay \n\nAnd earlier:\n\nOn Jul 12, 2013, at 12:05, Jonathan Nieder wrote:\n> Subject: Re: [PATCH] http.c: fix parsing of \n> http.sslCertPasswordProtected variable\n>\n> this change looks good.\n>\n> Reviewed-by: Jonathan Nieder \n\nso I will drop it from any future series and just refer to it in the \ncover letter as you suggest.\n\n\n> As to allowing GIT_SSL_CERT_PASSWORD_PROTECTED=no, I agree that it\n> does not belong to the http.*. configuration series\n\n\nAgreed. Will not include it in any future http.*. series.\n\n\n> If the other patches have any textual dependency, you can\n> make it [1/n] of your series and we can treat it just like f1ff763a,\n> that is, make sure it is solid regardless of the rest of the series,\n> and make it advance before the remainder of the series, so that we\n> can still replace http.*. implementation on top of these two\n> freely.\n\nGot it. Will do that and keep it in a single series.\n\nThanks for the direction,\n\nKyle\n"}]}