{"thread":{"id":"2671","subject":"git-send-mail in sh","startedAt":"2005-11-25T09:45:41Z","lastAt":"2005-11-29T13:04:22Z","messageCount":22,"participants":["Andreas Ericsson","Nikolai Weibull","Johannes Schindelin","Fernando J. Pereda","Junio C Hamano","Ryan Anderson","A Large Angry SCM","Yann Dirson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12720","messageId":"4386DD45.6030308@op5.se","threadId":"2671","inReplyTo":null,"subject":"git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-25T09:45:41Z","receivedAt":"2005-11-25T09:45:41Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Finally giving up on git-send-email (I won't install the 6 perl-modules \nit requires and I don't know perl enough to remove the need for them), I \nhacked up a replacement in sh. It's more aptly named as well. ;)\n\nIt tries to be fairly newbie-friendly in what it accepts so that new \ndevelopers on a project easily can submit patches upstream in the \ndesired format.\n\nThis is just a draft. If anyone thinks it's a good idea then say so and \nI'll write the man-page and re-submit it as a proper patch.\n\nIt's better than the perl version because;\n1. It doesn't have any requirements other than normal unix-commands and \n\"mail\" being in the path.\n2. It can generate the patches on the fly, using git-format-patch.\n\nIt's worse than the perl version because;\n1. It doesn't thread the patch-series (which I personally prefer anyway \nsince it's easier to follow a thread on a particular patch that way).\n2. The patches sent within the same second arrive in random order.\n\nSorry about the attachment btw. Thunderbird seems to wrap lines no \nmatter what I tell it.\n\nThoughts? Comments?\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12721","messageId":"20051125101209.GA8868@puritan.petwork","threadId":"2671","inReplyTo":"4386DD45.6030308@op5.se","subject":"Re: git-send-mail in sh","fromName":"Nikolai Weibull","fromEmail":"mailing-lists.git@rawuncut.elitemail.org","sentAt":"2005-11-25T10:12:09Z","receivedAt":"2005-11-25T10:12:09Z","isPatch":false,"sender":{"key":"mailing-lists.git@rawuncut.elitemail.org","avatar":null},"body":"Andreas Ericsson wrote:\n\n> Finally giving up on git-send-email (I won't install the 6 perl-modules \n> it requires and I don't know perl enough to remove the need for them), I \n> hacked up a replacement in sh. It's more aptly named as well. ;)\n\n> It's better than the perl version because;\n> 1. It doesn't have any requirements other than normal unix-commands and \n> \"mail\" being in the path.\n> 2. It can generate the patches on the fly, using git-format-patch.\n\nGreat!\n\n> It's worse than the perl version because;\n> 1. It doesn't thread the patch-series (which I personally prefer anyway \n> since it's easier to follow a thread on a particular patch that way).\n\nNot so great.  Why is it so much more difficult to have one more level\nof nesting?  It's annoying, but it's a lot less annoying than having 19\nseparate threads that are all, in fact, related to each other.\n\n> 2. The patches sent within the same second arrive in random order.\n\nPerhaps adding a 'sleep 1' would help?  (The delay may be unacceptable\nto some people, though.)\n\n        nikolai\n\n-- \nNikolai Weibull: now available free of charge at http://bitwi.se/!\nBorn in Chicago, IL USA; currently residing in Gothenburg, Sweden.\nmain(){printf(&linux[\"\\021%six\\012\\0\"],(linux)[\"have\"]+\"fun\"-97);}\n"},{"id":"12723","messageId":"4386EE7B.7070604@op5.se","threadId":"2671","inReplyTo":"20051125101209.GA8868@puritan.petwork","subject":"Re: git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-25T10:59:07Z","receivedAt":"2005-11-25T10:59:07Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nikolai Weibull wrote:\n>>It's worse than the perl version because;\n>>1. It doesn't thread the patch-series (which I personally prefer anyway \n>>since it's easier to follow a thread on a particular patch that way).\n> \n> \n> Not so great.  Why is it so much more difficult to have one more level\n> of nesting?  It's annoying, but it's a lot less annoying than having 19\n> separate threads that are all, in fact, related to each other.\n> \n\nI am of the opinion that nesting is bad because some patches get a few \ncomments while some others get them in droves. It's easy to miss those \nwith few if they're all nested. As for finding them, all the threads \nshould show up next to each other since there's practically no delay \nbetween sending them.\n\nAs for implementation, I don't think most \"mail\" programs have the \nfunctionality necessary to do so (dunno though since I didn't investigate).\n\n> \n>>2. The patches sent within the same second arrive in random order.\n> \n> \n> Perhaps adding a 'sleep 1' would help?  (The delay may be unacceptable\n> to some people, though.)\n> \n\nI thought about that, but decided against it.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12725","messageId":"Pine.LNX.4.63.0511251200190.30119@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2671","inReplyTo":"4386DD45.6030308@op5.se","subject":"Re: git-send-mail in sh","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-25T11:05:54Z","receivedAt":"2005-11-25T11:05:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 25 Nov 2005, Andreas Ericsson wrote:\n\n> It's worse than the perl version because;\n> 1. It doesn't thread the patch-series (which I personally prefer anyway since\n> it's easier to follow a thread on a particular patch that way).\n\nI think you can do that easily by providing a Message-ID: and a \nReferences: header. The id could be made up by \"git-$commit_id\" to be \nreasonably unique.\n\n> 2. The patches sent within the same second arrive in random order.\n\nI have that all the time. Sometimes, I send emails to the git list \nseveral minutes apart, and they come out in the wrong order. So it is no \nproblem.\n\n> Sorry about the attachment btw. Thunderbird seems to wrap lines no \n> matter what I tell it.\n\nThe hints in SubmittingPatches did not help?\n\n> Thoughts? Comments?\n\nI find it very cool. And easy to read. Just a few nits: You could use \ngit-sh-setup.sh to ensure that you're in a valid git repository. Also, you \ncould reuse the \"die\" function contained therein instead of a new \nfunction, \"abort\".\n\nCiao,\nDscho\n"},{"id":"12726","messageId":"20051125110651.GA9924@ferdyx.org","threadId":"2671","inReplyTo":"4386EE7B.7070604@op5.se","subject":"Re: git-send-mail in sh","fromName":"Fernando J. Pereda","fromEmail":"ferdy@ferdyx.org","sentAt":"2005-11-25T11:06:51Z","receivedAt":"2005-11-25T11:06:51Z","isPatch":false,"sender":{"key":"ferdy@ferdyx.org","avatar":"https://gravatar.com/avatar/96bf7c1ddf7ccd430255bd12d9d42b212dbc033b28c668a2bdf9c3995aa81e61?d=mp&s=160"},"body":"On Fri, Nov 25, 2005 at 11:59:07AM +0100, Andreas Ericsson wrote:\n| As for implementation, I don't think most \"mail\" programs have the \n| functionality necessary to do so (dunno though since I didn't investigate).\n\nYou can always generate a 'valid' mail message and use the sendmail\nbinary directly. That way you can set proper Message-Id: and proper\nReferences: and/or In-Reply-To: in the following mails.\n\nCheers,\nFerdy\n\n-- \nFernando J. Pereda Garcimartín\nGentoo Developer (Alpha,net-mail,mutt,git)\n20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4\n"},{"id":"12727","messageId":"7v7jaxou5b.fsf@assigned-by-dhcp.cox.net","threadId":"2671","inReplyTo":"4386DD45.6030308@op5.se","subject":"Re: git-send-mail in sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-25T11:15:44Z","receivedAt":"2005-11-25T11:15:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> It's better than the perl version because;\n\nGood.\n\n> It's worse than the perl version because;\n> 1. It doesn't thread the patch-series (which I personally prefer anyway \n> since it's easier to follow a thread on a particular patch that way).\n\nI think that is an improvement, actually ;-)\n\n> 2. The patches sent within the same second arrive in random order.\n\nI think you can fudge the \"Date: \" yourself.  Count the number\nof messages you are going to send out, grab the wallclock time\nbefore starting to send the first message, subtract that number\nof seconds and give it to the first message, add 1 second and\ngive it to the second message, and so on.\n\n3. It does not CC signers and authors.  Although I personally\nconsider not doing it \"better\", some people _might_ want to keep\nthat behaviour as an option.\n\n> # Instead of applying the 8942 chars long RFC-exact regex to\n> # match recipients email addresses against, we're satisfied with\n> # a simple @ somewhere inside an argument and just assume that\n> # people won't try anything obviously stupid\n\nThis is probably adequate in practice.  I have not seen an\ne-mail address other than local-part@domain (RFC2822-speak\n\"addr-spec\") form of mailbox on the kernel list for some time.\n\n> function usage() {\n> \techo \"Usage: git submit upstream@email.org <commit-ish> [<commit-ish>]\"\n> \texit 1\n> }\n\nI'm old fashioned and tend to omit noise word \"function\".\n\nThe original format-patch parameters are my fault, but I'd\nrather see newly written commands done like this:\n\n\t\"git-send-email\" <param>+\n\n        <param> = <patch> | <addressee> | <commits>\n        <patch> = <anything that passes \"test -f\">\n\t<addressee> = <RFC2822 addr-spec>\n        <commits> = \"..\" <top> | <bottom> \"..\" <top> | <commit>\n\t<bottom> = <extended SHA1 expression>\n\t<top>    = <extended SHA1 expression>\n\t<commit> = <extended SHA1 expression>\n\n * ..<top> is a shorthand of \"origin\"..<top> (the choice of\n   \"origin\" might be debatable, but probably sane).\n\n * <bottom>..<top> pair is to format changes in <top> but not in\n   <bottom>; typically <top> is the name of a topic branch, and\n   <bottom> is typically \"origin\".  This is to encourage the use\n   of topic branches.\n\n * <commit> is a shorthand for <commit>^1..<commit>; this is to\n   allow you to quickly pick just one commit and send it out.\n\n> function abort() {\n> \techo \"Aborting.\"\n> \texit 0\n> }\n\nAbort but exit 0?  You do not seem to be using it though ;-).\n\n> commits=0\n> if [ \"$com1\" ]; then\n> \tif [ -z \"$com2\" ]; then\n> \t\tcom2=\"$com1\"\n> \t\tcom1=HEAD\n> \tfi\n>\n> \tcommits=$(git rev-list $com1 ^$com2 | wc -l)\n> fi\n\nYou do not want to count commits like this.  format-patch drops\npatches that are already in upstream even if they are recorded\nas diffrent commit objects, so the number you get from rev-list\nis just an upper bound, and may not match the number of commits\nthat would be formatted.\n\n> [ $commits -eq 0 -a -z \"$patches\" ] && usage\n\nAnd I'd probably drop this one as well; you can have the check\nbefore sending things out, right?\n\n> # [ \"$email\" ] || git repo-config --get patch_email_address\n\nStoring the default addressee in the config is a good idea,\nsince typically e-mail submissions are to a single address.\n\n> [ $commits -gt 1 ] && opts=-n\n\nYou can always say -n if you want to do this; format-patch -n\nwith a single patch would not say [PATCH 1/1].\n\n> for patch in $(git format-patch $opts $com2 $com1 | sed 's/^* //'); do\n> \tpatches=\"$patches $patch\"\n> done\n\nThis is the first script I saw that uses the standard output\nfrom format-patch, and I do not think nobody else used it so\nfar.  If the standard output from format-patch is useful like\nthis, I would like to drop the '* ' prefix from it, so that you\ndo not have to sed it out.\n\nYou would probably want to do \"format-patch -o $tmpdir\" at least\nnot to smudge the toplevel directory.\n"},{"id":"12730","messageId":"43871ED8.9040506@op5.se","threadId":"2671","inReplyTo":"Pine.LNX.4.63.0511251200190.30119@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-25T14:25:28Z","receivedAt":"2005-11-25T14:25:28Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> \n>>Sorry about the attachment btw. Thunderbird seems to wrap lines no \n>>matter what I tell it.\n> \n> \n> The hints in SubmittingPatches did not help?\n> \n\nNopes. Perhaps because I started editing the message before I changed \nthe settings. I'll investigate further and make amendments if necessary.\n\n> \n>>Thoughts? Comments?\n> \n> \n> I find it very cool. And easy to read. Just a few nits: You could use \n> git-sh-setup.sh to ensure that you're in a valid git repository. Also, you \n> could reuse the \"die\" function contained therein instead of a new \n> function, \"abort\".\n> \n\nWill do. Thanks for the feedback.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12731","messageId":"20051125163358.GF16995@mythryan2.michonline.com","threadId":"2671","inReplyTo":"4386DD45.6030308@op5.se","subject":"Re: git-send-mail in sh","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-11-25T16:33:58Z","receivedAt":"2005-11-25T16:33:58Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Fri, Nov 25, 2005 at 10:45:41AM +0100, Andreas Ericsson wrote:\n> Finally giving up on git-send-email (I won't install the 6 perl-modules \n> it requires and I don't know perl enough to remove the need for them), I \n> hacked up a replacement in sh. It's more aptly named as well. ;)\n\nScanning the list, 2 are related to option handling (one of which is\nbuiltin), one isn't used (Data::Dumper), and two are related to sending\nvalid emails. The email address verification is ridiculously hard to get\ncorrect, so using pre-written code for that seemed justified.\n\n> It's worse than the perl version because;\n> 1. It doesn't thread the patch-series (which I personally prefer anyway \n> since it's easier to follow a thread on a particular patch that way).\n\nYou can use --no-chain-reply-to in git-send-email.perl, and put a 0/N\nmessage in, and all subsequent replies get attached to that instead of\nin order, if you want.  This keeps everything in one thread, but all as\nresponses to the first email, so the people that want everything in one\nthread can get that behavior.\n\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"12732","messageId":"43874415.8040302@op5.se","threadId":"2671","inReplyTo":"20051125163358.GF16995@mythryan2.michonline.com","subject":"Re: git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-25T17:04:21Z","receivedAt":"2005-11-25T17:04:21Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ryan Anderson wrote:\n> On Fri, Nov 25, 2005 at 10:45:41AM +0100, Andreas Ericsson wrote:\n> \n>>Finally giving up on git-send-email (I won't install the 6 perl-modules \n>>it requires and I don't know perl enough to remove the need for them), I \n>>hacked up a replacement in sh. It's more aptly named as well. ;)\n> \n> \n> Scanning the list, 2 are related to option handling (one of which is\n> builtin), one isn't used (Data::Dumper), and two are related to sending\n> valid emails.\n\n\nWhen I try to install Email::Valid (using apt) it wants an additional \ntwo modules. Mail::Sendmail wants one other, so that's Data::Dumper, the \ntwo actually used and the three those two use. Six, for short.\n\n\n> The email address verification is ridiculously hard to get\n> correct, so using pre-written code for that seemed justified.\n> \n\nBut it isn't necessary to validate it to such exactness. Nothing worse \nwill happen than the user chiding himself for his butterfingers if \nhe/she makes a mistake.\n\nBesides, I think typos are by far the most common error. Those are \nusually valid email addresses while still not being correct.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12733","messageId":"438747E5.80608@gmail.com","threadId":"2671","inReplyTo":"43871ED8.9040506@op5.se","subject":"Re: git-send-mail in sh","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-11-25T17:20:37Z","receivedAt":"2005-11-25T17:20:37Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Andreas Ericsson wrote:\n> Johannes Schindelin wrote:\n...\n>> The hints in SubmittingPatches did not help?\n>>\n> \n> Nopes. Perhaps because I started editing the message before I changed \n> the settings. I'll investigate further and make amendments if necessary.\n\nDefinitely need to do the settings changes *before* opening the compose \nwindow for them to have an effect.\n"},{"id":"12734","messageId":"43874935.2080804@op5.se","threadId":"2671","inReplyTo":"7v7jaxou5b.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-25T17:26:13Z","receivedAt":"2005-11-25T17:26:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n>>It's worse than the perl version because;\n>>1. It doesn't thread the patch-series (which I personally prefer anyway \n>>since it's easier to follow a thread on a particular patch that way).\n> \n> \n> I think that is an improvement, actually ;-)\n> \n\nAgreed to that then. Good thing since that was the hardest to solve.\n\n> \n>>2. The patches sent within the same second arrive in random order.\n> \n> \n> I think you can fudge the \"Date: \" yourself.  Count the number\n> of messages you are going to send out, grab the wallclock time\n> before starting to send the first message, subtract that number\n> of seconds and give it to the first message, add 1 second and\n> give it to the second message, and so on.\n> \n> 3. It does not CC signers and authors.  Although I personally\n> consider not doing it \"better\", some people _might_ want to keep\n> that behaviour as an option.\n> \n\nIt doesn't CC them, but any number of email-addresses can be specified \non the command line (so long as they don't include spaces, but that can \nbe taken care of).\n\nThese below needs a bit of clarification. It's friday afternoon here, so \nI'm a bit slow.\n\n>         <commits> = \"..\" <top> | <bottom> \"..\" <top> | <commit>\n> \t<bottom> = <extended SHA1 expression>\n> \t<top>    = <extended SHA1 expression>\n> \t<commit> = <extended SHA1 expression>\n> \n>  * ..<top> is a shorthand of \"origin\"..<top> (the choice of\n>    \"origin\" might be debatable, but probably sane).\n> \n\nI'd rather specify the entry-point, as in \"get all patches from this \ncommit to HEAD\", if only one commit is specified, so:\n\n\tgit-send-patch git@vger.kernel.org origin\n\nwould do just that.\n\n>  * <bottom>..<top> pair is to format changes in <top> but not in\n>    <bottom>; typically <top> is the name of a topic branch, and\n>    <bottom> is typically \"origin\".  This is to encourage the use\n>    of topic branches.\n> \n\nWould that be\n\n\tgit-send-patch origin..HEAD\n\nto get the changes in the current branch since head?\n\n>  * <commit> is a shorthand for <commit>^1..<commit>; this is to\n>    allow you to quickly pick just one commit and send it out.\n> \n\nMarvellous the things one learn. I didn't know about that syntax before. :)\n\n> \n>># [ \"$email\" ] || git repo-config --get patch_email_address\n> \n> \n> Storing the default addressee in the config is a good idea,\n> since typically e-mail submissions are to a single address.\n> \n\nIf values can have spaces there can be any number of email-addresses.\n\n> \n>>[ $commits -gt 1 ] && opts=-n\n> \n> \n> You can always say -n if you want to do this; format-patch -n\n> with a single patch would not say [PATCH 1/1].\n> \n\nDidn't know that. Good thing though.\n\n> \n> This is the first script I saw that uses the standard output\n> from format-patch, and I do not think nobody else used it so\n> far.  If the standard output from format-patch is useful like\n> this, I would like to drop the '* ' prefix from it, so that you\n> do not have to sed it out.\n> \n\nI'll do that then. It doesn't really add any value anyways.\n\n> You would probably want to do \"format-patch -o $tmpdir\" at least\n> not to smudge the toplevel directory.\n> \n\nPerhaps support the -o flag in git-send-patch?\n\nI'm wondering if it wouldn't be better to move much of \ngit-format-patch's functionality to git-send-patch and support a \n\"--todisk\" option. After all, how many patches are created but not sent \nanywhere?\n\nThat way we could rework the syntax to only support that of \ngit-rev-list. I think it's the most standard-like thing there is in git.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12735","messageId":"7vwtiwmvfp.fsf@assigned-by-dhcp.cox.net","threadId":"2671","inReplyTo":"43874935.2080804@op5.se","subject":"Re: git-send-mail in sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-25T18:30:50Z","receivedAt":"2005-11-25T18:30:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> It doesn't CC them, but any number of email-addresses can be specified \n> on the command line (so long as they don't include spaces, but that can \n> be taken care of).\n\nAgain I do not think I'd ever use that feature from the original\nsend-email myself, but the difference is that this CC list\ndepends on each commit (sign-offs taken from a commit are\nadded to CC list for only that commit).\n\n>>  * <bottom>..<top> pair is to format changes in <top> but not in\n>>    <bottom>; typically <top> is the name of a topic branch, and\n>>    <bottom> is typically \"origin\".  This is to encourage the use\n>>    of topic branches.\n>\n> Would that be\n>\n> \tgit-send-patch origin..HEAD\n>\n> to get the changes in the current branch since head?\n\nYes, and that could be spelled \"git-send-patch ..HEAD\" as well,\nif we go with my suggestion to default <bottom> to \"origin\".\n\n>>  * <commit> is a shorthand for <commit>^1..<commit>; this is to\n>>    allow you to quickly pick just one commit and send it out.\n>\n> Marvellous the things one learn. I didn't know about that syntax before. :)\n\nJust to make sure you did not misunderstand me, I meant: the\nproposed program acts as if <commit>^1..<commit> was given when\nsingle <commit> is given.\n\nBut you are right.  We could make a single <commit> a short-hand\nfor \"origin\"..<commit>; if somebody wants to pick just one\ncommit from a topic branch, he can always say <commit>^1..<commit>.\n\n> I'm wondering if it wouldn't be better to move much of \n> git-format-patch's functionality to git-send-patch and support a \n> \"--todisk\" option. After all, how many patches are created but not sent \n> anywhere?\n\nManymanymanymanymany.  I do all my rebases and cherry-picks via\nformat-patch piped to git-am, and obviously they are never sent\nout.\n"},{"id":"12776","messageId":"7vpsonp3r3.fsf@assigned-by-dhcp.cox.net","threadId":"2671","inReplyTo":"43874935.2080804@op5.se","subject":"Re: git-send-mail in sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-26T20:12:48Z","receivedAt":"2005-11-26T20:12:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Subject: [PATCH] format-patch: output filename reported to stdout verbatim.\n\nPrepending asterisk to the output was just adding noise, and\nforcing scripts like git-send-mail proposed by Andreas Ericsson\ndo unnecessary work.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n Andreas Ericsson <ae@op5.se> writes:\n\n > Junio C Hamano wrote:\n >\n >> ...  If the standard output from format-patch is useful like\n >> this, I would like to drop the '* ' prefix from it, so that you\n >> do not have to sed it out.\n >\n > I'll do that then. It doesn't really add any value anyways.\n\n Agreed, so I'll push this out in the next batch.\n\n git-format-patch.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\napplies-to: 9ccf8849fa9b522a344645c2f28f12ab036e30d5\n51b3c00e9d95371a9ad202204f01c5981f241b20\ndiff --git a/git-format-patch.sh b/git-format-patch.sh\nindex bc56876..9b40880 100755\n--- a/git-format-patch.sh\n+++ b/git-format-patch.sh\n@@ -268,7 +268,7 @@ do\n     file=`printf '%04d-%stxt' $i \"$title\"`\n     if test '' = \"$stdout\"\n     then\n-\t    echo \"* $file\"\n+\t    echo \"$file\"\n \t    process_one >\"$outdir$file\"\n \t    if test t = \"$check\"\n \t    then\n@@ -279,7 +279,7 @@ do\n \t\t:\n \t    fi\n     else\n-\t    echo >&2 \"* $file\"\n+\t    echo >&2 \"$file\"\n \t    process_one\n     fi\n     i=`expr \"$i\" + 1`\n---\n@@GIT_VERSION@@\n"},{"id":"12780","messageId":"4388E33A.8000004@op5.se","threadId":"2671","inReplyTo":"7vwtiwmvfp.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-26T22:35:38Z","receivedAt":"2005-11-26T22:35:38Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n> \n>>It doesn't CC them, but any number of email-addresses can be specified \n>>on the command line (so long as they don't include spaces, but that can \n>>be taken care of).\n> \n> \n> Again I do not think I'd ever use that feature from the original\n> send-email myself, but the difference is that this CC list\n> depends on each commit (sign-offs taken from a commit are\n> added to CC list for only that commit).\n> \n\nHad a thinko when I wrote that. I've added --cc-signers, --cc-author and \n--cc (for both --cc-signers and --cc-author).\n\n> But you are right.  We could make a single <commit> a short-hand\n> for \"origin\"..<commit>;\n\n\nActually, I meant that a single <commit> would mean \"<commit>..HEAD\", \nlike git-format-patch does it. Doing the other way around in a tool so \nclosely coupled would be very confusing, I think.\n\nHere's what I have on disk right now. The ${var##*^} syntax was decided \nto be portable in some earlier discussion, so I'm sticking with it \n(mostly because I don't know how to do it with expr and Junio pokes me \nwhen I do it with sed. Enlightenment welcome).\n\nif [ \"$com2\" ]; then\n     range=\"$com1..$com2\"\nelse\n     case \"$com1\" in\n         ?*..?*)\n             # nicely ranged already\n             range=\"$com1\"\n             ;;\n         ..)\n             range=origin..HEAD\n             ;;\n         ?*^)\n             # single commit\n             com1=\"${com1##*^}\"\n             range=\"$com1^1..$com1\"\n             ;;\n         ?*^[0-9]|?*^[0-9][0-9])\n             # series of commits, ranging back from <commit-ish>\n             range=\"$com1..${com1%%^*}\"\n             ;;\n         ^[0-9]|^[0-9][0-9])\n             # series of commits, ranging back from HEAD\n             range=\"HEAD$com1..HEAD\"\n             ;;\n         *)\n             range=\"$com1..HEAD\"\n             ;;\n     esac\nfi\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12781","messageId":"20051126233434.GL3393@nowhere.earth","threadId":"2671","inReplyTo":"7v7jaxou5b.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-send-mail in sh","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-26T23:34:35Z","receivedAt":"2005-11-26T23:34:35Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Nov 25, 2005 at 03:15:44AM -0800, Junio C Hamano wrote:\n> > function usage() {\n> > \techo \"Usage: git submit upstream@email.org <commit-ish> [<commit-ish>]\"\n> > \texit 1\n> > }\n> \n> I'm old fashioned and tend to omit noise word \"function\".\n\nMore importantly, it is not portable.\n-- \nYann Dirson    <ydirson@altern.org> |\nDebian-related: <dirson@debian.org> |   Support Debian GNU/Linux:\n                                    |  Freedom, Power, Stability, Gratis\n     http://ydirson.free.fr/        | Check <http://www.debian.org/>\n"},{"id":"12819","messageId":"7v4q5xbvip.fsf@assigned-by-dhcp.cox.net","threadId":"2671","inReplyTo":"4388E33A.8000004@op5.se","subject":"Re: git-send-mail in sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-27T22:01:18Z","receivedAt":"2005-11-27T22:01:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> Here's what I have on disk right now. The ${var##*^} syntax was decided \n> to be portable in some earlier discussion, so I'm sticking with it \n> (mostly because I don't know how to do it with expr and Junio pokes me \n> when I do it with sed. Enlightenment welcome).\n\nThe ${parameter##word} syntax is in IEEE 1003.1-2001, and bash,\nksh, and dash seem to work with it.  That does not necessarily\nmean it is \"portable\" but I won't be so worried about shells\nthat do not grok this.  Input from people on non-Linux platforms\nare appreciated.\n\n> if [ \"$com2\" ]; then\n>     range=\"$com1..$com2\"\n> else\n>     case \"$com1\" in\n>...\n>         ?*^)\n>             # single commit\n>             com1=\"${com1##*^}\"\n>             range=\"$com1^1..$com1\"\n>             ;;\n\nI wonder if you meant \"${com1%^}\" here, to remove the trailing '^'.\n\n>         ?*^[0-9]|?*^[0-9][0-9])\n>             # series of commits, ranging back from <commit-ish>\n>             range=\"$com1..${com1%%^*}\"\n>             ;;\n>         ^[0-9]|^[0-9][0-9])\n>             # series of commits, ranging back from HEAD\n>             range=\"HEAD$com1..HEAD\"\n>             ;;\n\nN generation back in extended SHA1 notation uses a tilde '~',\ne.g. \"HEAD~5\" is five commits back from the current HEAD, so I'd\nprefer being consistent with that (HEAD^5 means the fifth parent\nof an octopus merge commit).  Also limiting to between 0 and 99\ngenerations misinterprets \"HEAD~123\".\n\nAlthough checking only the letter that follows the tilde is a\ndigit mistakenly accepts something like \"master~1-bad-one\", that\nis already malformed and whatever comes downstream would barf,\nso that may be fine.  How about something like:\n\n\t?*'~'[1-9]*)\n        \trange=\"$com1..${com1%~*}\" ;;\n\t'~'[1-9]*)\n        \trange=\"HEAD$com1..HEAD\" ;;\n\nI do not have aversion against echo piped to sed in general, by\nthe way.  I *would* redicule people who write something like\nthis, though:\n\n\tcase \"$git\" in\n        */.git)\tprintname=`echo \"$git\" | sed -e 's/\\/\\.git$//'` ;;\n        *)\tprintname=$git ;;\n\tesac\n\nIt should be spelled `expr \"$git\" : '\\(.*\\)/\\.git$'` (or\n\"${git%/.git}\" if we know the shell is POSIX), for this\nparticular one, since we already know it ends with \"/.git\".  But\nif all you want to do is to drop an *optional* trailing \"/.git\"\n(i.e. your input may or may not end with \"/.git\"), a single:\n\n\tprintname=`echo \"$git\" | sed -e 's/\\/\\.git$//'`\n\nwithout surrounding case may be adequate; it forks sed when it\ndoes not have the optional /.git part, though.  And if you are\ndropping optional /.git or .git (think of prettyprinting\nuemacs/.git and git.git), then echo-to-sed without surrounding\n\"case\" is probably easier to read:\n\n\tprintname=`echo \"$git\" | sed -e 's/\\/*\\.git$//'`\n\nunless you want to avoid fork, in which case it would be:\n\n\tcase \"$git\" in\n        */.git) printname=${git%/.git} ;;\n        *.git) printname=${git%.git} ;;\n        *) printname=$git ;;\n\tesac\n"},{"id":"12825","messageId":"438A426B.7070607@op5.se","threadId":"2671","inReplyTo":"7v4q5xbvip.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-27T23:34:03Z","receivedAt":"2005-11-27T23:34:03Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n>>            # single commit\n>>            com1=\"${com1##*^}\"\n>>            range=\"$com1^1..$com1\"\n>>            ;;\n> \n> \n> I wonder if you meant \"${com1%^}\" here, to remove the trailing '^'.\n> \n\nI did/do/done. :)\n\n> \n>>        ?*^[0-9]|?*^[0-9][0-9])\n>>            # series of commits, ranging back from <commit-ish>\n>>            range=\"$com1..${com1%%^*}\"\n>>            ;;\n>>        ^[0-9]|^[0-9][0-9])\n>>            # series of commits, ranging back from HEAD\n>>            range=\"HEAD$com1..HEAD\"\n>>            ;;\n> \n> \n> N generation back in extended SHA1 notation uses a tilde '~',\n\n\nI just noticed that after sending the original email. I've changed it to \ntake tilde instead.\n\n> Also limiting to between 0 and 99\n> generations misinterprets \"HEAD~123\".\n> \n> Although checking only the letter that follows the tilde is a\n> digit mistakenly accepts something like \"master~1-bad-one\", that\n> is already malformed and whatever comes downstream would barf,\n> so that may be fine.  How about something like:\n> \n> \t?*'~'[1-9]*)\n>         \trange=\"$com1..${com1%~*}\" ;;\n> \t'~'[1-9]*)\n>         \trange=\"HEAD$com1..HEAD\" ;;\n> \n\nFine by me, although that 99 patches limit was sort of semi-intentional. \nDoing it this way makes case order matter since\n\t?*'~'[1-9]*\n\nwill also match\n\n\t<commit>~3..HEAD\n\nI'll stick with your way though and put a comment there so people don't \ntouch the ordering.\n\n\nThanks for the expr lesson btw.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12827","messageId":"20051128001541.GB8811@puritan.petwork","threadId":"2671","inReplyTo":"7v4q5xbvip.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-send-mail in sh","fromName":"Nikolai Weibull","fromEmail":"mailing-lists.git@rawuncut.elitemail.org","sentAt":"2005-11-28T00:15:41Z","receivedAt":"2005-11-28T00:15:41Z","isPatch":false,"sender":{"key":"mailing-lists.git@rawuncut.elitemail.org","avatar":null},"body":"Junio C Hamano wrote:\n\n> The ${parameter##word} syntax is in IEEE 1003.1-2001, and bash, ksh,\n> and dash seem to work with it.\n\nYou can add Zsh to that list.\n\n        nikolai\n\n-- \nNikolai Weibull: now available free of charge at http://bitwi.se/!\nBorn in Chicago, IL USA; currently residing in Gothenburg, Sweden.\nmain(){printf(&linux[\"\\021%six\\012\\0\"],(linux)[\"have\"]+\"fun\"-97);}\n"},{"id":"12831","messageId":"438A5401.3070008@michonline.com","threadId":"2671","inReplyTo":"43874415.8040302@op5.se","subject":"Re: git-send-mail in sh","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-11-28T00:49:05Z","receivedAt":"2005-11-28T00:49:05Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"Andreas Ericsson wrote:\n> Ryan Anderson wrote:\n> \n>> On Fri, Nov 25, 2005 at 10:45:41AM +0100, Andreas Ericsson wrote:\n>>\n>>> Finally giving up on git-send-email (I won't install the 6\n>>> perl-modules it requires and I don't know perl enough to remove the\n>>> need for them), I hacked up a replacement in sh. It's more aptly\n>>> named as well. ;)\n>>\n>> Scanning the list, 2 are related to option handling (one of which is\n>> builtin), one isn't used (Data::Dumper), and two are related to sending\n>> valid emails.\n> \n> When I try to install Email::Valid (using apt) it wants an additional\n> two modules. Mail::Sendmail wants one other, so that's Data::Dumper, the\n> two actually used and the three those two use. Six, for short.\n\nCan I ask why you aren't willing to install packages, such as those?  I\ncan understand a reluctance to install modules directly from CPAN, on an\notherwise package-managed system, but I'm afraid I must confess to\npuzzlement over a reluctance to use pre-packaged modules.\n\nThe major flaw in git-send-email, from my perspective, was a lack of\nsupport for SMTP AUTH, for situations like Junio's, where the local MTA\n(and thus \"mail\" as well) are not configured to handle SMTP AUTH. Moving\nto a purely shell based replacement seems to make this an even harder\nfeature to support.  (Though, admittedly, I haven't even made an attempt\nto add it to the Perl version yet.)\n\n>> The email address verification is ridiculously hard to get\n>> correct, so using pre-written code for that seemed justified.\n>>\n> \n> But it isn't necessary to validate it to such exactness. Nothing worse\n> will happen than the user chiding himself for his butterfingers if\n> he/she makes a mistake.\n> \n> Besides, I think typos are by far the most common error. Those are\n> usually valid email addresses while still not being correct.\n\nFair enough.\n"},{"id":"12852","messageId":"438AC7A0.7030407@op5.se","threadId":"2671","inReplyTo":"438A5401.3070008@michonline.com","subject":"Re: git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-28T09:02:24Z","receivedAt":"2005-11-28T09:02:24Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ryan Anderson wrote:\n> Andreas Ericsson wrote:\n> \n>>When I try to install Email::Valid (using apt) it wants an additional\n>>two modules. Mail::Sendmail wants one other, so that's Data::Dumper, the\n>>two actually used and the three those two use. Six, for short.\n> \n> \n> Can I ask why you aren't willing to install packages, such as those?  I\n> can understand a reluctance to install modules directly from CPAN, on an\n> otherwise package-managed system, but I'm afraid I must confess to\n> puzzlement over a reluctance to use pre-packaged modules.\n> \n\nI don't like having lots of junk installed. Besides, I do a lot of \ndevelopment work for the Openwall distro which tries fairly hard to get \naway without installing lots of cruft. I'd rather not taint it with \npackages from other vendors since I do a fair amount of RPM building and \ntesting on it but I still want to be able to use git on it.\n\n\n> The major flaw in git-send-email, from my perspective, was a lack of\n> support for SMTP AUTH, for situations like Junio's, where the local MTA\n> (and thus \"mail\" as well) are not configured to handle SMTP AUTH. Moving\n> to a purely shell based replacement seems to make this an even harder\n> feature to support.  (Though, admittedly, I haven't even made an attempt\n> to add it to the Perl version yet.)\n> \n\nBy \"local\" do you mean \"local on Junio's laptop\" or \"local at cox.net\"?\n\n\"mail\" uses the \"local on Junio's laptop\" SMTP server so he can \nconfigure it any way he wants.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12857","messageId":"7v64qdxgiz.fsf@assigned-by-dhcp.cox.net","threadId":"2671","inReplyTo":"438AC7A0.7030407@op5.se","subject":"Re: git-send-mail in sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-28T09:34:12Z","receivedAt":"2005-11-28T09:34:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> By \"local\" do you mean \"local on Junio's laptop\" or \"local at cox.net\"?\n>\n> \"mail\" uses the \"local on Junio's laptop\" SMTP server so he can \n> configure it any way he wants.\n\nI am puzzled.  What if I do not run any SMTP server on the\nlaptop and use ISP's SMTP server?  Right now my ISP's SMTP\nserver does not seem to require AUTH, so it is not an issue for\nme, though..\n"},{"id":"12930","messageId":"438C51D6.8050207@op5.se","threadId":"2671","inReplyTo":"7v64qdxgiz.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-send-mail in sh","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-29T13:04:22Z","receivedAt":"2005-11-29T13:04:22Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n> \n>>By \"local\" do you mean \"local on Junio's laptop\" or \"local at cox.net\"?\n>>\n>>\"mail\" uses the \"local on Junio's laptop\" SMTP server so he can \n>>configure it any way he wants.\n> \n> \n> I am puzzled.  What if I do not run any SMTP server on the\n> laptop and use ISP's SMTP server?  Right now my ISP's SMTP\n> server does not seem to require AUTH, so it is not an issue for\n> me, though..\n> \n\nIt uses whatever the /bin/mail program on your system uses. This is \nusually done by spooling the mail for delivery by the local MTA which \ndoesn't have to listen to any ports anywhere (mutt and friends work the \nsame way).\n\nHaving an MTA installed is a requirement of the LSB. The /bin/mail \nprogram requires that it's running, which the sendmail binary doesn't. \nThe sendmail binary is always shipped along with an MTA though, so to \nget around having one at all one would have to re-implement the SMTP \nprotocol (which Mail::Sendmail does, but without authentication). I can \ndo that in C if you like. That way you can have support for SMTP over \nSSL with all sorts of funny authentication mechanisms.\n\nThe good thing about using the local MTA is that you get that for free \nwith very thoroughly tested code and you only have to set it up once \nrather than passing all the auth stuff repeatedly on the command-line \neach time you want to submit a patch.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"}]}