{"thread":{"id":"23366","subject":"[PATCH v9] Documentation/remote-helpers: Add invocation section","startedAt":"2010-04-07T05:57:12Z","lastAt":"2010-04-10T12:36:58Z","messageCount":19,"participants":["Ramkumar Ramachandra","Junio C Hamano","Jonathan Nieder","Sverre Rabbelier","Michael J Gruber"],"isPatch":true,"patchVersion":9,"patchTotal":null},"messages":[{"id":"138807","messageId":"g2vf3271551004062257ycbda64d3z3d3004d802a03fc3@mail.gmail.com","threadId":"23366","inReplyTo":null,"subject":"[PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-07T05:57:12Z","receivedAt":"2010-04-07T05:57:12Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Add an 'Invocation' section to specify what the command line arguments\nmean. Also include a link to git-remote in the 'See Also' section.\n\nSigned-off-by: Ramkumar Ramachandra \n---\n Changes: The second argument may be an arbitrary string as\n Jonathan pointed out.\n\n Documentation/git-remote-helpers.txt | 34 +++++++++++++++++++++++++++++++++-\n 1 files changed, 33 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-remote-helpers.txt\nb/Documentation/git-remote-helpers.txt\nindex 7a5569c..b0e7d54 100644\n--- a/Documentation/git-remote-helpers.txt\n+++ b/Documentation/git-remote-helpers.txt\n@@ -7,7 +7,7 @@ git-remote-helpers - Helper programs to interact with\nremote repositories\n\n SYNOPSIS\n --------\n-'git remote-' \n+'git remote-' []\n\n DESCRIPTION\n -----------\n@@ -38,6 +38,34 @@ transport protocols, such as 'git-remote-http',\n'git-remote-https',\n 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities\n 'fetch', 'option', and 'push'.\n\n+INVOCATION\n+----------\n+\n+Remote helper programs are invoked with one or (optionally) two\n+arguments. The first argument specifies a remote repository as in git;\n+it is either the name of a configured remote or a URL. The second\n+argument specifies a URL; it is usually of the form\n+'://
', but any arbitrary string is possible.\n+\n+When git encounters a URL of the form '://
', where\n+'' is a protocol that it cannot handle natively, it\n+automatically invokes 'git remote-' with the full URL as\n+the second argument. If such a URL is encountered directly on the\n+command line, the first argument is the same as the second, and if it\n+is encountered in a configured remote, the first argument is the name\n+of that remote.\n+\n+A URL of the form '::
' explicitly instructs git to\n+invoke 'git remote-' with '
' as the second\n+argument. If such a URL is encountered directly on the command line,\n+the first argument is '
', and if it is encountered in a\n+configured remote, the first argument is the name of that remote.\n+\n+Additionally, when a configured remote has 'remote..vcs' set to\n+'', git explicitly invokes 'git remote-' with\n+'' as the first argument. If set, the second argument is\n+'remote..url'; otherwise, the second argument is omitted.\n+\n COMMANDS\n --------\n\n@@ -206,6 +234,10 @@ OPTIONS\n \tmust not rely on this option being set before\n \tconnect request occurs.\n\n+SEE ALSO\n+--------\n+linkgit:git-remote[1]\n+\n Documentation\n -------------\n Documentation by Daniel Barkalow and Ilari Liusvaara\n-- \n1.7.0.3\n"},{"id":"138814","messageId":"w2wf3271551004070156ia98bcb9cre81baa3d862bb19b@mail.gmail.com","threadId":"23366","inReplyTo":"g2vf3271551004062257ycbda64d3z3d3004d802a03fc3@mail.gmail.com","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-07T08:56:30Z","receivedAt":"2010-04-07T08:56:30Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Junio,\n\nI see that you've applied v8 of my patch to pu, but there's a small\nchange in this revision:\n\ndiff --git a/Documentation/git-remote-helpers.txt\nb/Documentation/git-remote-helpers.txt\nindex 8838388..6ffc0da 100644\n--- a/Documentation/git-remote-helpers.txt\n+++ b/Documentation/git-remote-helpers.txt\n@@ -44,9 +44,8 @@ INVOCATION\n Remote helper programs are invoked with one or (optionally) two\n arguments. The first argument specifies a remote repository as in git;\n it is either the name of a configured remote or a URL. The second\n-argument specifies a URL of the form '://
' or\n-'::
', where '
' may be an arbitrary\n-string.\n+argument specifies a URL; it is usually of the form\n+'://
', but any arbitrary string is possible.\n\n When git encounters a URL of the form '://
', where\n '' is a protocol that it cannot handle natively, it\n\n-- Ram\n"},{"id":"138840","messageId":"7vsk77e20r.fsf@alter.siamese.dyndns.org","threadId":"23366","inReplyTo":"g2vf3271551004062257ycbda64d3z3d3004d802a03fc3@mail.gmail.com","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-07T15:05:40Z","receivedAt":"2010-04-07T15:05:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"You keep sending a broken patch. I've queued v7 and replaced with v8 and\nboth times I had to fix them in my editor.\n\nI'm not replacing v8 with this tonight, as my pre-push test cycles are\nalready running (finished in one vm and continuing in another). Please\ncheck what I queued and make sure your future patches applies on top of\nwhat I have.\n\nThanks.\n"},{"id":"138856","messageId":"n2nf3271551004070950ucf314b40g56087d49dfbd29f1@mail.gmail.com","threadId":"23366","inReplyTo":"7vsk77e20r.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-07T16:50:52Z","receivedAt":"2010-04-07T16:50:52Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"> You keep sending a broken patch.  I've queued v7 and replaced with v8 and\n> both times I had to fix them in my editor.\n\nOh, thanks for telling me- I should make sure that my future patches\naren't broken.\nCan someone tell me what I'm doing wrong? Earlier, Junio also had a\nproblem with one of my patches being corrupt. I used git-imap-send and\nthe GMail web interface to fill out the \"to\", \"cc\" and some comments.\n\n> I'm not replacing v8 with this tonight, as my pre-push test cycles are\n> already running (finished in one vm and continuing in another).\n\nOkay, no issues.\n\n> Please\n> check what I queued and make sure your future patches applies on top of\n> what I have.\n\nRight, so you can just squash them. Also, I think I'm sending in\npatches too fast so I'll slow down and rebase them on top of `pu`\nevery time.\nDo tell me anything else that I can do to make my patches easier to\nreview and apply in future.\n\n-- Ram\n"},{"id":"138860","messageId":"7vzl1fch2d.fsf@alter.siamese.dyndns.org","threadId":"23366","inReplyTo":"n2nf3271551004070950ucf314b40g56087d49dfbd29f1@mail.gmail.com","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-07T17:23:38Z","receivedAt":"2010-04-07T17:23:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Can someone tell me what I'm doing wrong? Earlier, Junio also had a\n> problem with one of my patches being corrupt. I used git-imap-send and\n> the GMail web interface to fill out the \"to\", \"cc\" and some comments.\n\nIn the above procedure, up to imap-send, everything would be fine, but I\nheard GMail web interface still wraps lines before sending the result out.\n\nGmail section in Documentation/SubmittingPatches says:\n\n GMail does not appear to have any way to turn off line wrapping in the web\n interface, so this will mangle any emails that you send. You can however\n use any IMAP email client to connect to the google imap server, and forward\n the emails through that. Just make sure to disable line wrapping in that\n email client. Alternatively, use \"git send-email\" instead.\n\nThis is a tangent, but I think this can still be further improved. What\nit says is not incorrect per-se, but the \"can however\" gives a false hope\nto people who have been burned by the web interface. The fact it lists\nare:\n\n - GMail web interface will wrap lines and corrupt patches, no matter what\n you do;\n\n - With imap-send, you can stuff messages to your outbox at GMail, and\n using IMAP client that does _not_ corrupt messages, you can send things\n out.\n\nCombined together, these mean that you lose even if you preprare your\noutbox with imap-send if you send out the end result from their web\ninterface.\n\nAt the minimum, we could add a parenthesized comment like this.\n\n the emails through that. Just make sure to disable line wrapping in\n that email client (again, there is no way to tell GMail web interface to\n do so).\n"},{"id":"138864","messageId":"l2jf3271551004071058sd2828bccr9eb5319715865bc8@mail.gmail.com","threadId":"23366","inReplyTo":"7vzl1fch2d.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-07T17:58:00Z","receivedAt":"2010-04-07T17:58:00Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":">  - GMail web interface will wrap lines and corrupt patches, no matter what\n>   you do;\n>\n>  - With imap-send, you can stuff messages to your outbox at GMail, and\n>   using IMAP client that does _not_ corrupt messages, you can send things\n>   out.\n\nActually the last paragraph about \"git imap-send\" clearly states that\nthe web interface _can_ be used. I just used another email client to\nfind out when lines break and when they don't- I've accordingly\nwritten a patch for Documentation/SubmittingPatches clarifying this.\n\n-- Ram\n"},{"id":"138901","messageId":"20100407224942.GA20239@progeny.tock","threadId":"23366","inReplyTo":"n2nf3271551004070950ucf314b40g56087d49dfbd29f1@mail.gmail.com","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-07T22:49:43Z","receivedAt":"2010-04-07T22:49:43Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> Right, so you can just squash them. Also, I think I'm sending in\n> patches too fast so I'll slow down and rebase them on top of `pu`\n> every time.\n\nThank you for this. FWIW I find it useful when discussing a piece of\ncode or documentation to bounce back and forth multiple versions of\nsmall fragments. Then once the discussion has settled down, it can be\nuseful to see the big picture again, with the new changes\nincorporated.\n\nIf you want to make sure the latest version of a patch is always\navailable, that is a noble goal, too, but I think a frequently-\nrebased public branch for your patch series is a better way to achieve\nthat.\n\nUnrelated: in case you are interested, the git-resurrect.sh script\nfrom contrib can extract topic branches from pu, if you want to see\nJunio’s topic branch for your patch.\n\nCheers,\nJonathan\n"},{"id":"138903","messageId":"7vzl1eamss.fsf@alter.siamese.dyndns.org","threadId":"23366","inReplyTo":"20100407224942.GA20239@progeny.tock","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-07T23:02:43Z","receivedAt":"2010-04-07T23:02:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> If you want to make sure the latest version of a patch is always\n> available, that is a noble goal, too, but I think a frequently-\n> rebased public branch for your patch series is a better way to achieve\n> that.\n>\n> Unrelated: in case you are interested, the git-resurrect.sh script\n> from contrib can extract topic branches from pu, if you want to see\n> Junio’s topic branch for your patch.\n\nIt might look unrelated, but I found it the most helpful information in\nyour message ;-) I really hate it when people base their patches on 'pu'.\n\nAt least it would be helpful for me if people based their follow-up\npatches on top of their own topics.\n"},{"id":"138920","messageId":"x2of3271551004072154r62d10023r32e74064d38aff75@mail.gmail.com","threadId":"23366","inReplyTo":"7vzl1eamss.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-08T04:54:34Z","receivedAt":"2010-04-08T04:54:34Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nOn Thu, Apr 8, 2010 at 4:19 AM, Jonathan Nieder wrote:\n> Thank you for this.  FWIW I find it useful when discussing a piece of\n> code or documentation to bounce back and forth multiple versions of\n> small fragments.  Then once the discussion has settled down, it can be\n> useful to see the big picture again, with the new changes\n> incorporated.\n\nGot it. In future, I'll post diffs for smaller changes hopefully in\nthe same email thread, and complete patches for larger changes in a\nseparate email thread. I've been quite haphazard in the past.\n\n> If you want to make sure the latest version of a patch is always\n> available, that is a noble goal, too, but I think a frequently-\n> rebased public branch for your patch series is a better way to achieve\n> that.\n\nAh, I already do that, but my branch is based on `pu`. What should I do?\nhttp://github.com/artagnon/git\n\nOn Thu, Apr 8, 2010 at 4:32 AM, Junio C Hamano wrote:\n> At least it would be helpful for me if people based their follow-up\n> patches on top of their own topics.\n\nCan I see the topic branch corresponding to my patches? If this is\npossible, I can avoid the more painful procedure of extracting it from\nthe latest pu using git-resurrect.sh.\n\n-- Ram\n"},{"id":"138921","messageId":"20100408050323.GA5987@progeny.tock","threadId":"23366","inReplyTo":"x2of3271551004072154r62d10023r32e74064d38aff75@mail.gmail.com","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-08T05:03:24Z","receivedAt":"2010-04-08T05:03:24Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> Can I see the topic branch corresponding to my patches? If this is\n> possible, I can avoid the more painful procedure of extracting it from\n> the latest pu using git-resurrect.sh.\n\nI tend to do the extraction by hand:\n\n 1. git log --first-parent origin/pu\n 2. Search for \"rr/\".\n 3. git branch -f rr/whatever \n\nMaybe it would be nice to have a script that does just that instead of\nthe more costly \"git resurrect -m rr/whatever\".\n\nCheers,\nJonathan\n"},{"id":"138923","messageId":"7vk4si8r02.fsf@alter.siamese.dyndns.org","threadId":"23366","inReplyTo":"x2of3271551004072154r62d10023r32e74064d38aff75@mail.gmail.com","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-08T05:14:53Z","receivedAt":"2010-04-08T05:14:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Can I see the topic branch corresponding to my patches? If this is\n> possible, I can avoid the more painful procedure of extracting it from\n> the latest pu using git-resurrect.sh.\n\nRun:\n\n $ git log --first-parent --oneline origin/master..origin/pu\n\nand find \"Merge branch 'rr/remote-helper-doc'\" in the output. The second\nparent of that merge commit (e.g. 6144af5^2 == ad466d1) is the tip of your\ntopic. You can verify it with:\n\n $ git log -p origin/master..ad466d1\n $ git checkout -b remote-helper-doc ad466d1\n ... build further on it ...\n"},{"id":"138976","messageId":"h2ifabb9a1e1004081152hbca48fbex11134249aef9df14@mail.gmail.com","threadId":"23366","inReplyTo":"7vzl1eamss.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-08T18:52:12Z","receivedAt":"2010-04-08T18:52:12Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Apr 8, 2010 at 01:02, Junio C Hamano wrote:\n> It might look unrelated, but I found it the most helpful information in\n> your message ;-) I really hate it when people base their patches on 'pu'.\n>\n> At least it would be helpful for me if people based their follow-up\n> patches on top of their own topics.\n\nHmmm, perhaps we should update SubmittingPatches to say something\nabout that? The section that talks about what to base your patch\nagainst [0] is not very explicit in that aspect.\n\n[0] http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches#l106\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"138984","messageId":"7vfx3567e2.fsf_-_@alter.siamese.dyndns.org","threadId":"23366","inReplyTo":"h2ifabb9a1e1004081152hbca48fbex11134249aef9df14@mail.gmail.com","subject":"Re*: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-08T20:01:25Z","receivedAt":"2010-04-08T20:01:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> Hmmm, perhaps we should update SubmittingPatches to say something\n> about that? The section that talks about what to base your patch\n> against is not very explicit in that aspect.\n\nOk, here is a rough draft.\n\n Documentation/SubmittingPatches | 52 ++++++++++++++++++++++++++++++--------\n 1 files changed, 41 insertions(+), 11 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex c686f86..1d403ee 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -53,6 +53,37 @@ But the patch submission requirements are a lot more relaxed\n here on the technical/contents front, because the core GIT is\n thousand times smaller ;-). So here is only the relevant bits.\n \n+(0) Decide what to base your work on.\n+\n+The general principle is always to base your work on the oldest branch\n+that your change is relevant to.\n+\n+ - A fix for a bug that has been with git from older releases should be\n+ included in both the upcoming feature release and the current\n+ maintenance release. Try to base your work on the 'maint' branch. A\n+ work to kill a bug that is in 'master' but not in 'maint' should be\n+ based on 'master'.\n+\n+ - A fix for a bug that is not yet in 'master' is the best bug to kill.\n+ If you can find the topic that introduces the regression, base your\n+ work on the tip of the topic. \"log --first-parent master..pu\" would be\n+ a good way to find the tips of topic branches.\n+\n+ - A new feature should be based on the 'master' branch in general.\n+\n+ - If your new feature depends on some other topics that are not in\n+ 'master' yet, and if it relies only on one topic, base your work on the\n+ tip of that topic. If it depends on too many topics that are not in\n+ 'master', you can privately start working on 'next' or even 'pu' and\n+ send out your patches for discussion, but it is possible that your\n+ maintainer may ask you to wait and rebase your changes on 'master'\n+ after some of the larger topics your topic depends on graduate to\n+ 'master'.\n+\n+ - Base corrections and enhancements on a topic that are not in 'master'\n+ yet but already merged to 'next' on the tip of the topic. If the topic\n+ has not been merged to 'next', it is Ok to add a note that the patch is\n+ a trivial fix and can be squashed into the series.\n \n (1) Make separate commits for logically separate changes.\n \n@@ -170,17 +201,16 @@ patch, format it as \"multipart/signed\", not a text/plain message\n that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is\n not a text/plain, it's something else.\n \n-Note that your maintainer does not necessarily read everything\n-on the git mailing list. If your patch is for discussion first,\n-send it \"To:\" the mailing list, and optionally \"cc:\" him. If it\n-is trivially correct or after the list reached a consensus, send\n-it \"To:\" the maintainer and optionally \"cc:\" the list for\n-inclusion.\n-\n-Also note that your maintainer does not actively involve himself in\n-maintaining what are in contrib/ hierarchy. When you send fixes and\n-enhancements to them, do not forget to \"cc: \" the person who primarily\n-worked on that hierarchy in contrib/.\n+Unless your patch is a very trivial and an obviously correct one,\n+first send it with \"To:\" set to the mailing list, with \"cc:\" listing\n+people who are involved in the area you are touching (the output from\n+\"git blame $path\" and \"git shortlog --no-merges $path\" would help to\n+identify them), to solicit comments and reviews. After the list\n+reached a consensus that it is a good idea to apply the patch, re-send\n+it with \"To:\" set to the maintainer and optionally \"cc:\" the list for\n+inclusion. Do not forget to add trailers such as \"Acked-by:\",\n+\"Reviewed-by:\" and \"Tested-by:\" after your \"Signed-off-by:\" line as\n+necessary.\n \n \n (4) Sign your work\n"},{"id":"138985","messageId":"r2ifabb9a1e1004081321ia91ad7f7r58f39b9173594af1@mail.gmail.com","threadId":"23366","inReplyTo":"7vfx3567e2.fsf_-_@alter.siamese.dyndns.org","subject":"Re: Re*: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-08T20:21:44Z","receivedAt":"2010-04-08T20:21:44Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Apr 8, 2010 at 22:01, Junio C Hamano wrote:\n> Ok, here is a rough draft.\n\nI like it, but...\n\n> -Note that your maintainer does not necessarily read everything\n> -on the git mailing list.\n\n> -Also note that your maintainer does not actively involve himself in\n> -maintaining what are in contrib/ hierarchy.\n\n... I'm curious as to why you removed these two statements.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"138988","messageId":"7v634165bv.fsf@alter.siamese.dyndns.org","threadId":"23366","inReplyTo":"r2ifabb9a1e1004081321ia91ad7f7r58f39b9173594af1@mail.gmail.com","subject":"Re: Re*: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-08T20:45:56Z","receivedAt":"2010-04-08T20:45:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> I like it, but...\n>\n>> -Note that your maintainer does not necessarily read everything\n>> -on the git mailing list.\n>\n>> -Also note that your maintainer does not actively involve himself in\n>> -maintaining what are in contrib/ hierarchy.\n>\n> ... I'm curious as to why you removed these two statements.\n\nThe rewritten paragraph already covers these two points, no? Proposals\ncan be cc:ed to me only if what I did in the past is relevant to the\nproposal, meaning \"treat the maintainer just like any other contributors\nand reviewers\", and it applies to all the codebase, not just the contrib/\narea.\n"},{"id":"138995","messageId":"4BBE8BA1.1080101@drmicha.warpmail.net","threadId":"23366","inReplyTo":"7vfx3567e2.fsf_-_@alter.siamese.dyndns.org","subject":"Re: Re*: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-04-09T02:06:25Z","receivedAt":"2010-04-09T02:06:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 09.04.2010 04:01:\n> Sverre Rabbelier writes:\n> \n>> Hmmm, perhaps we should update SubmittingPatches to say something\n>> about that? The section that talks about what to base your patch\n>> against is not very explicit in that aspect.\n> \n> Ok, here is a rough draft.\n> \n> Documentation/SubmittingPatches | 52 ++++++++++++++++++++++++++++++--------\n> 1 files changed, 41 insertions(+), 11 deletions(-)\n> \n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index c686f86..1d403ee 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -53,6 +53,37 @@ But the patch submission requirements are a lot more relaxed\n> here on the technical/contents front, because the core GIT is\n> thousand times smaller ;-). So here is only the relevant bits.\n> \n> +(0) Decide what to base your work on.\n> +\n> +The general principle is always to base your work on the oldest branch\n> +that your change is relevant to.\n> +\n> + - A fix for a bug that has been with git from older releases should be\n> + included in both the upcoming feature release and the current\n> + maintenance release. Try to base your work on the 'maint' branch. A\n> + work to kill a bug that is in 'master' but not in 'maint' should be\n> + based on 'master'.\n> +\n> + - A fix for a bug that is not yet in 'master' is the best bug to kill.\n> + If you can find the topic that introduces the regression, base your\n> + work on the tip of the topic. \"log --first-parent master..pu\" would be\n> + a good way to find the tips of topic branches.\n> +\n> + - A new feature should be based on the 'master' branch in general.\n> +\n> + - If your new feature depends on some other topics that are not in\n> + 'master' yet, and if it relies only on one topic, base your work on the\n> + tip of that topic. If it depends on too many topics that are not in\n> + 'master', you can privately start working on 'next' or even 'pu' and\n> + send out your patches for discussion, but it is possible that your\n> + maintainer may ask you to wait and rebase your changes on 'master'\n> + after some of the larger topics your topic depends on graduate to\n> + 'master'.\n> +\n> + - Base corrections and enhancements on a topic that are not in 'master'\n> + yet but already merged to 'next' on the tip of the topic. If the topic\n> + has not been merged to 'next', it is Ok to add a note that the patch is\n> + a trivial fix and can be squashed into the series.\n> \n> (1) Make separate commits for logically separate changes.\n> \n> @@ -170,17 +201,16 @@ patch, format it as \"multipart/signed\", not a text/plain message\n> that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is\n> not a text/plain, it's something else.\n> \n> -Note that your maintainer does not necessarily read everything\n> -on the git mailing list. If your patch is for discussion first,\n> -send it \"To:\" the mailing list, and optionally \"cc:\" him. If it\n> -is trivially correct or after the list reached a consensus, send\n> -it \"To:\" the maintainer and optionally \"cc:\" the list for\n> -inclusion.\n> -\n> -Also note that your maintainer does not actively involve himself in\n> -maintaining what are in contrib/ hierarchy. When you send fixes and\n> -enhancements to them, do not forget to \"cc: \" the person who primarily\n> -worked on that hierarchy in contrib/.\n> +Unless your patch is a very trivial and an obviously correct one,\n> +first send it with \"To:\" set to the mailing list, with \"cc:\" listing\n> +people who are involved in the area you are touching (the output from\n> +\"git blame $path\" and \"git shortlog --no-merges $path\" would help to\n> +identify them), to solicit comments and reviews. After the list\n> +reached a consensus that it is a good idea to apply the patch, re-send\n> +it with \"To:\" set to the maintainer and optionally \"cc:\" the list for\n> +inclusion. Do not forget to add trailers such as \"Acked-by:\",\n> +\"Reviewed-by:\" and \"Tested-by:\" after your \"Signed-off-by:\" line as\n> +necessary.\n\nI'm wondering how necessary that flipping of to and cc is. It means one\nhas to switch one's send-email config between RFCs and actual patches.\nIt also means I should send fewer patches to you (Junio) directly (in\naddition to cc'ing the list), which is probably the intention :)\nOK, I've learned about aliasesfile (and wondered about the different\nwording compared to aliasfiletype) meanwhile, so no problem...\n\n> \n> \n> (4) Sign your work\n"},{"id":"139110","messageId":"7v7hofzyvu.fsf@alter.siamese.dyndns.org","threadId":"23366","inReplyTo":"4BBE8BA1.1080101@drmicha.warpmail.net","subject":"Re: Re*: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-10T04:59:17Z","receivedAt":"2010-04-10T04:59:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> I'm wondering how necessary that flipping of to and cc is. It means one\n> has to switch one's send-email config between RFCs and actual patches.\n\nThis was my thinko. \"An ideal patch flow\" says the final submission still\ngoes to the list with maintainer on the Cc: line, and that is fine with\nme.\n\n> It also means I should send fewer patches to you (Junio) directly (in\n> addition to cc'ing the list), which is probably the intention :)\n\nThat, and more importantly, less uncooked patches hitting my mailbox with\nme as an addressee, was an important goal. I need to deal with patch\ne-mails in three different ways:\n\n (0) just read as a bystander without much interesting input from my side;\n (1) read and comment for improvement; or\n (2) act on it by applying.\n\nI was hoping if we can have some way for me to sift (2) from others\nwithout adding extra burden on the contributors.\n\nOne way to reduce (1) I've been experimenting with is not to comment on\ntoo many threads. The theory is that the initial rfc patch hopefully does\nnot have my address on To/Cc, but once I comment on a patch, follow-up\npatches will be posted with address of everybody involved in the\ndiscussion Cc:ed to the thread (which by the way is a good practice and I\ndo not want people to break it), and my \"grep for patch messages with my\naddress on it\" trick to find the finalized patches will not work well.\n\nBut that strategy does not work very well for another reason: we lose one\nreviewer if I try to comment on patches as little as possible, and we do\nnot have enough people who read other's patches and help polishing to\nafford that.\n"},{"id":"139146","messageId":"z2tf3271551004100524w9b8cf62ck7e889f87b7f2cb8e@mail.gmail.com","threadId":"23366","inReplyTo":"7vk4si8r02.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-10T12:24:26Z","receivedAt":"2010-04-10T12:24:26Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\n>    $ git log --first-parent --oneline origin/master..origin/pu\n>\n> and find \"Merge branch 'rr/remote-helper-doc'\" in the output.  The second\n> parent of that merge commit (e.g. 6144af5^2 == ad466d1) is the tip of your\n> topic.  You can verify it with:\n>\n>    $ git log -p origin/master..ad466d1\n>    $ git checkout -b remote-helper-doc ad466d1\n>    ... build further on it ...\n\nThanks for the excellent instructions. I'm just curious: why didn't\nyou include these instructions in your rewrite of SubmittingPatches?\n\n-- Ram\n"},{"id":"139147","messageId":"m2jf3271551004100536q65725be3i224c7e7fb334563@mail.gmail.com","threadId":"23366","inReplyTo":"7vfx3567e2.fsf_-_@alter.siamese.dyndns.org","subject":"Re: Re*: [PATCH v9] Documentation/remote-helpers: Add invocation section","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-10T12:36:58Z","receivedAt":"2010-04-10T12:36:58Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI like the idea, but I think it's too verbose. Perhaps something along\nthese lines?\n\n1. In general, base your patches on 'master'.\n2. If your patch is a bugfix try to base it on 'maint'. If the bug's\nin 'master, but not in 'maint' also, base it on 'master'.\n3. If you're working on a feature, some of whose patches are already\nin 'pu', base your work on the tip of the last commit in your topic\nbranch (See THIS). If it's a minor correction, you might want to add a\nnote asking the maintainer to squash it into the previous commit.\n4. If you're working on an elaborate feature that depends on many\ncommits in 'pu', maintain a public branch based on 'pu', and\nperiodically post patches to the mailing list for feedback (all based\non 'pu'). You might have to rebase/ wait before it's finally merged.\n\nTHIS:\n> +   work on the tip of the topic.  \"log --first-parent master..pu\" would be\n> +   a good way to find the tips of topic branches.\n\n+ \"The grandparent of this merge commit is your latest commit in this\ntopic. This is the commit you should base your patch on.\"\n\n-- Ram\n"}]}