{"thread":{"id":"7870","subject":"FEATURE REQUEST: git-format-path: Add option to encode patch content","startedAt":"2007-04-27T11:31:15Z","lastAt":"2007-04-30T22:18:50Z","messageCount":20,"participants":["Jari Aalto","Johannes Schindelin","Alex Riesen","Junio C Hamano","Robin H. Johnson","Carl Worth","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40590","messageId":"ps5qyry4.fsf@cante.net","threadId":"7870","inReplyTo":null,"subject":"FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-04-27T11:31:15Z","receivedAt":"2007-04-27T11:31:15Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"\nFEAURE REQUEST\n--------------\n\nAdd sme option to git-format-path to encode thae patch content \n(MIME/base64)\n\nRATIONALE\n-------------\n\nI need to submit patches that fix trailing whitespcaes, and to guard\nthose in email message it would be nice if the patch could be made\ninto base64 envelope (or MIME)\n\n-- Jari\n"},{"id":"40594","messageId":"Pine.LNX.4.64.0704271541010.12006@racer.site","threadId":"7870","inReplyTo":"ps5qyry4.fsf@cante.net","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-27T13:43:05Z","receivedAt":"2007-04-27T13:43:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Apr 2007, Jari Aalto wrote:\n\n> FEAURE REQUEST\n> --------------\n> \n> Add sme option to git-format-path to encode thae patch content \n> (MIME/base64)\n\nAlthough you ask politely, and have a good explanation why you need it, \nthere is a strong sentiment in some Git developers (most notably, Git's \ninventor) against this kind of support.\n\nYou might have more luck when you decide to implement it yourself, and \nsubmit it, though (if it is not too intrusive, I see people adding it, if \nonly to add even more rope to those willing to hang themselves).\n\nHaving said that, I think that you can actually teach every mail app \n(except maybe web-based ones) to respect formatting, including white \nspace.\n\nCiao,\nDscho\n"},{"id":"40618","messageId":"d51pzpqo.fsf@cante.net","threadId":"7870","inReplyTo":"Pine.LNX.4.64.0704271541010.12006@racer.site","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-04-27T17:33:35Z","receivedAt":"2007-04-27T17:33:35Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Fri, 27 Apr 2007, Jari Aalto wrote:\n>\n>> FEAURE REQUEST\n>> --------------\n>> \n>> Add sme option to git-format-path to encode thae patch content \n>> (MIME/base64)\n>\n> Although you ask politely, and have a good explanation why you need it, \n> there is a strong sentiment in some Git developers (most notably, Git's \n> inventor) against this kind of support.\n>\n> You might have more luck when you decide to implement it yourself, and \n> submit it, though (if it is not too intrusive, I see people adding it, if \n> only to add even more rope to those willing to hang themselves).\n>\n> Having said that, I think that you can actually teach every mail app \n> (except maybe web-based ones) to respect formatting, including white \n> space.\n\nI hope the development team considers this. There is another uses case\nthat I can think of too:\n\n- Sending non us-ascii patches (different langauge)\n\nFor documentation or code (Java/XML allows UTF-8). \n\nJari\n"},{"id":"40622","messageId":"20070427192917.GA23169@steel.home","threadId":"7870","inReplyTo":"d51pzpqo.fsf@cante.net","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-27T19:29:17Z","receivedAt":"2007-04-27T19:29:17Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jari Aalto, Fri, Apr 27, 2007 19:33:35 +0200:\n> > Having said that, I think that you can actually teach every mail app \n> > (except maybe web-based ones) to respect formatting, including white \n> > space.\n> \n> I hope the development team considers this. There is another uses case\n> that I can think of too:\n> \n> - Sending non us-ascii patches (different langauge)\n\nnot a good use case: you can send text/plain mails with UTF-8 content\njust as easily. And the patches will apply.\n\nP.S. You ignored the suggestion to implement base64. Why?\n"},{"id":"40625","messageId":"7vslalmwcx.fsf@assigned-by-dhcp.cox.net","threadId":"7870","inReplyTo":"ps5qyry4.fsf@cante.net","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-27T19:49:02Z","receivedAt":"2007-04-27T19:49:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jari Aalto writes:\n\n> FEAURE REQUEST\n> --------------\n>\n> Add sme option to git-format-path to encode thae patch content \n> (MIME/base64)\n\nOne possibility is to have a separate mail sending or formatting\nprogram that works on format-patch output. In any case, I feel\nthat _generating_ base64 natively does not belong to core git.\nWe _tolerate_ MIME in mailinfo, but that does not mean we\nencourage MIME. Keeping patches reviewable in recipient's MUA\nis important.\n\nNow, after having given the \"official\" party-line answer, I\npersonally think it would make sense to always do base64 when\nattaching the patch (i.e. \"--attach\", not \"--inline\").\n\nIn the community git originates from, even --inline attachments\nare frowned upon, let alone --attach multiparts (yes, I am\ntalking about the kernel list and this list). Nobody who sends\npatches over e-mail in communities that have a tradition against\nunreadable patches would be using --inline nor --attach anyway,\nso making --attach to do base64 would not hurt there.\n\nOn the other hand, in circles whose recipients are prepared to\n(or even \"prefer to\") accept messages formatted with --attach,\nthere should be no harm done if the patch text is base64\nencoded either.\n\nAm I going to do it? Not likely. But if a patch is cleanly\ndone, I do not think there is much reason to reject one.\n"},{"id":"40627","messageId":"20070427203534.GA7846@curie-int.orbis-terrarum.net","threadId":"7870","inReplyTo":"7vslalmwcx.fsf@assigned-by-dhcp.cox.net","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2007-04-27T20:35:34Z","receivedAt":"2007-04-27T20:35:34Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Fri, Apr 27, 2007 at 12:49:02PM -0700, Junio C Hamano wrote:\n> On the other hand, in circles whose recipients are prepared to\n> (or even \"prefer to\") accept messages formatted with --attach,\n> there should be no harm done if the patch text is base64\n> encoded either.\n+1 for having this feature on my end.\n\nI do some work on other projects where patches that aren't multipart\naren't even accepted (the author has an applying system that he bounces\nthe patches into, and refuses to change it :-( ) [again, projects that\naren't git upstream, but I track with git because that makes development\nmuch easier].\n\n-- \nRobin Hugh Johnson\nGentoo Linux Developer & Council Member\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"40632","messageId":"87y7kdo6pn.wl%cworth@cworth.org","threadId":"7870","inReplyTo":"7vslalmwcx.fsf@assigned-by-dhcp.cox.net","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-27T21:20:04Z","receivedAt":"2007-04-27T21:20:04Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 27 Apr 2007 12:49:02 -0700, Junio C Hamano wrote:\n> Keeping patches reviewable in recipient's MUA is important.\n\nAbsolutely.\n\n> In the community git originates from, even --inline attachments\n> are frowned upon, let alone --attach multiparts (yes, I am\n> talking about the kernel list and this list). Nobody who sends\n> patches over e-mail in communities that have a tradition against\n> unreadable patches would be using --inline nor --attach anyway,\n> so making --attach to do base64 would not hurt there.\n\nI know I'm not within the kernel or git party line by saying this, but\nI don't have a problem with (non base64) mime-attached patches. My MUA\ndisplays them fine and quotes them when I reply so I can easily review\nthem.\n\nI have even wished that git-am would accept a message with multiple\nattachments and apply each in series. But, no, I'm not about to write\nthat myself either.\n\nInstead we've gotten by with using the output of \"git format-patch\n--stdout from..to > feature.patchset\" and attaching that. But even\nthen, I'd like something like git-am that knew how to process an email\nmessage like that, (that is, not trying to use the subject and from\nlines for commit information). As is, I just have to arrange for the\nattachment to get piped to git-am instead of the entire message.\n\nIf nothing else, there's a datapoint from a separate community that\nalso has a tradition against unreadable patches.\n\nMy MUA doesn't have support (that I know of) for piping a sequence of\nmessages to a command. Do your MUAs? If not, how do people generally\nhandle long sequences of [n/N] patch emails?\n\n-Carl\n"},{"id":"40633","messageId":"7vk5vxmrql.fsf@assigned-by-dhcp.cox.net","threadId":"7870","inReplyTo":"87y7kdo6pn.wl%cworth@cworth.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-27T21:28:50Z","receivedAt":"2007-04-27T21:28:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> My MUA doesn't have support (that I know of) for piping a sequence of\n> messages to a command. Do your MUAs? If not, how do people generally\n> handle long sequences of [n/N] patch emails?\n\nAre you asking _me_ specifically? Assuming so,\n\nYes, my MUA does allow \"next N messages\" or \"selected messages\"\nto be given to an external program.\n\nBut I typically save them in a separate mailbox for reviewing\nand in-editor fixups before applying, so \"next N messages\" are\nuseful to me for saving but not applying.\n"},{"id":"40634","messageId":"alpine.LFD.0.98.0704271430490.9964@woody.linux-foundation.org","threadId":"7870","inReplyTo":"87y7kdo6pn.wl%cworth@cworth.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-27T21:40:33Z","receivedAt":"2007-04-27T21:40:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 27 Apr 2007, Carl Worth wrote:\n> \n> My MUA doesn't have support (that I know of) for piping a sequence of\n> messages to a command. Do your MUAs? If not, how do people generally\n> handle long sequences of [n/N] patch emails?\n\nWell, in pine you *can* actually select a long sequence of messages, and \nthen \"a|\" to \"apply a pipe\" to them, and ask for them to be sent as-is, \nand thus push them directly to git-am if you wanted to.\n\nBut quite frankly, I've never done it. It's _much_ easier to just select \nthe messages, do \"as\" to \"apply save\", and just save them to a new mbox, \nand them apply that mbox in another xterm.\n\nOne reason I do that is that while I've trained my cadre of killer kernel \ndevelopment monkeys to send me emails in the proper format, I quite often \nend up editing away things like \"Hi, please apply\" and \"thanks\" etc. And I \nactually add my sign-offs manually.\n\n(Of course, my \"manual\" sign-off is often a \"search-and-replace\" of the \nprevious sign-off, so that I not only don't have to type that much, but \nalso so that my workflow automatically guarantees that I only sign off on \nstuff that was signed off by the sender, and I notice if my \nsearch-and-replace says that it replaced 213 entries, even though I \nexpected to have 214 emails there..)\n\nI'm sure there are mail clients that don't support even that kind of basic \nautomation (\"Please save each email individually! Because mousing around \nis good for you! It's the only exercise you get!\"), but I can't imagine \nthat anybody uses them. So the \"save to a file, go through it there, fix \nup, and apply\" sequence is a pretty good one. And it scales really well.\n\n(By \"scales really well\", I mean that I usually end up doing series of \njust a few emails. But occasionally I have batches either from a single \nuser, or multiple different people who I batch up in one go, and I do tens \nand even hundreds of patches in one \"go\" - I do *not* want to switch \nback-and-forth between the email client and another xterm, but at the same \ntime, email clients really aren't generally set up to doing things like \nsearch-and-replace etc on hundreds of messages at a time).\n\nI'm sure if you use GNU emacs to read email, you could do it all within \nthat emacs client, but I couldn't help you with that anyway.\n\n\t\tLinus\n"},{"id":"40636","messageId":"87wszxo2b5.wl%cworth@cworth.org","threadId":"7870","inReplyTo":"alpine.LFD.0.98.0704271430490.9964@woody.linux-foundation.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-27T22:55:10Z","receivedAt":"2007-04-27T22:55:10Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 27 Apr 2007 14:40:33 -0700 (PDT), Linus Torvalds wrote:\n> But quite frankly, I've never done it. It's _much_ easier to just select\n> the messages, do \"as\" to \"apply save\", and just save them to a new mbox,\n> and them apply that mbox in another xterm.\n\nOK. That's basically exactly the same mode I work with, (but I prefer\nthe user to just send me that mbox file as a single attachment rather\nthan broken out into separate messages). If nothing else, it\neliminates the \"select the messages\" step.\n\nAnd, sure I can see that where you need to aggregate dozens (or\nhundreds or whatever) of separate patches to apply in one go, it's\nreally nice that you can do that. Personally, I'm not in that\nsituation myself. Though if I were, I'd still be happy to have each\npatch-set submission be pre-aggregated for me. Maybe you're getting\nthat already with a single \"select thread\" operation or whatever.\n\nAnyway, thanks for satisfying some idle curiosity on my part.\n\n-Carl\n\nPS. A separate reason I like attachments is that I like the subject\nand message body to be the actual discussion of the patch, (and the\ncommit message and patch content to come later). I find that, (as\nopposed to commentary being inserted between commit message and patch\ncontent), more natural when a discussion on the mailing list turns\ninto a patch attempt. But I fully recognize this is a cultural\nseparation between my project and that of the kernel and git\nprojects---certainly nothing needing any debate.\n"},{"id":"40637","messageId":"alpine.LFD.0.98.0704271636130.9964@woody.linux-foundation.org","threadId":"7870","inReplyTo":"87wszxo2b5.wl%cworth@cworth.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-27T23:41:12Z","receivedAt":"2007-04-27T23:41:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 27 Apr 2007, Carl Worth wrote:\n> \n> PS. A separate reason I like attachments is that I like the subject\n> and message body to be the actual discussion of the patch, (and the\n> commit message and patch content to come later).\n\nAnd the reason I _hate_ attachements is that you cannot say \"no, that one \nis wrong\", and just skip/edit it.\n\nBecause once you start doing attachments, you're not going have just one \npatch per email. You're going to have people send you ten attachments in \none email for patches 1-10.\n\nAnd when patch 5 is crap, you're basically screwed. There is almost no \nsupport for replying to that _individually_ and saying \"That one sucks\". \nYou press \"reply\", and you get all ten.\n\nSo the fundamental rule *must* be: one patch, one email. That's the \nstarting point. Anything else is simply broken. \n\nAnd once you accept that fundamental rule (and quite frankly, I don't care \nif others accept it or not - I'm personally 100% convinved that anythign \nelse is a major mistake), suddenly attachments have no upsides at all, \nonly downsides. They mean that when you send the patch top a mailing list, \neverybody sees it differently, and a *lot* of people will be unable to \nreply to it with proper quoting.\n\n\t\tLinus\n"},{"id":"40638","messageId":"alpine.LFD.0.98.0704271644460.9964@woody.linux-foundation.org","threadId":"7870","inReplyTo":"alpine.LFD.0.98.0704271636130.9964@woody.linux-foundation.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-27T23:47:06Z","receivedAt":"2007-04-27T23:47:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 27 Apr 2007, Linus Torvalds wrote:\n>\n> And when patch 5 is crap, you're basically screwed. There is almost no \n> support for replying to that _individually_ and saying \"That one sucks\". \n> You press \"reply\", and you get all ten.\n\nBtw, this is true even when the attachment itself is just an mbox.\n\nYes, you can (and probably do) just save the mbox to a file, and then \nstart _another_ mail reader on that file. That's actually what I end up \ndoing a lot for my \"doit\" file (which is just where I save all the \nmessages that I'll apply) when I go through them more carefully.\n\nBut it doesn't change the fact that if you just see something wrong, you \ncan't just reply to it and say \"that's crap\". You have to basically exit \nyour primary mail-reader, and start a secondary one on the file you saved.\n\nAlso, I assume that this means that nobody else is ever Cc'd on the \npatches you get? Like a public mailing list?\n\n\t\tLinus\n"},{"id":"40639","messageId":"87tzv1nzd4.wl%cworth@cworth.org","threadId":"7870","inReplyTo":"alpine.LFD.0.98.0704271636130.9964@woody.linux-foundation.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-27T23:58:47Z","receivedAt":"2007-04-27T23:58:47Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 27 Apr 2007 16:41:12 -0700 (PDT), Linus Torvalds wrote:\n> And the reason I _hate_ attachements is that you cannot say \"no, that one\n> is wrong\", and just skip/edit it.\n\nWell, skipping it while applying the rest is bad form anyway, isn't\nit? I think \"bounce the whole series on any problem\" reduces load on\nthe maintainer and helps the submitter learn by fixing up the patch\nseries personally rather than trusting the maintainer to do it.\n\n> And when patch 5 is crap, you're basically screwed. There is almost no\n> support for replying to that _individually_ and saying \"That one sucks\".\n> You press \"reply\", and you get all ten.\n\nAs soon as there's anything broken in the series, the patch boundaries\naren't that interesting to me anymore. At that point, I just reply to\nthe whole thing and strip the reply down to the stuff worth commenting\non.\n\nSo, my style is accept or bounce, and during the bounce, I'll just\nreview the whole thing while quoted in my reply buffer.\n\nThat seems to work for me anyway, without a one-patch-per email\napproach, (in fact, one-patch-per-email would be a lot more awkward\nfor replying to the whole series and quoting similar or related issues\nas I like to do).\n\n-Carl\n"},{"id":"40640","messageId":"alpine.LFD.0.98.0704271719240.9964@woody.linux-foundation.org","threadId":"7870","inReplyTo":"87tzv1nzd4.wl%cworth@cworth.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-28T00:20:48Z","receivedAt":"2007-04-28T00:20:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 27 Apr 2007, Carl Worth wrote:\n> > And the reason I _hate_ attachements is that you cannot say \"no, that one\n> > is wrong\", and just skip/edit it.\n> \n> Well, skipping it while applying the rest is bad form anyway, isn't\n> it?\n\nWhy would it be?\n\nMaybe for small projects with strictly linear development, but I get a \n_lot_ of patch-series where the patches are independent of each other. \nAndrew's patch-series are one example, but so is a lot of the \"trivial \ntree\" patch-series too.\n\n\t\t\tLinus\n"},{"id":"40641","messageId":"7vtzv1l3oi.fsf@assigned-by-dhcp.cox.net","threadId":"7870","inReplyTo":"alpine.LFD.0.98.0704271719240.9964@woody.linux-foundation.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-28T00:53:49Z","receivedAt":"2007-04-28T00:53:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 27 Apr 2007, Carl Worth wrote:\n>> > And the reason I _hate_ attachements is that you cannot say \"no, that one\n>> > is wrong\", and just skip/edit it.\n>> \n>> Well, skipping it while applying the rest is bad form anyway, isn't\n>> it?\n>\n> Why would it be?\n>\n> Maybe for small projects with strictly linear development, but I get a \n> _lot_ of patch-series where the patches are independent of each other. \n> Andrew's patch-series are one example, but so is a lot of the \"trivial \n> tree\" patch-series too.\n\nSeconded, even for a small project like git.git, I do that all\nthe time.\n"},{"id":"40642","messageId":"7vps5pl3jl.fsf@assigned-by-dhcp.cox.net","threadId":"7870","inReplyTo":"87y7kdo6pn.wl%cworth@cworth.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-28T00:56:46Z","receivedAt":"2007-04-28T00:56:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n>> In the community git originates from, even --inline attachments\n>> are frowned upon, let alone --attach multiparts (yes, I am\n>> talking about the kernel list and this list). Nobody who sends\n>> patches over e-mail in communities that have a tradition against\n>> unreadable patches would be using --inline nor --attach anyway,\n>> so making --attach to do base64 would not hurt there.\n>\n> I know I'm not within the kernel or git party line by saying this, but\n> I don't have a problem with (non base64) mime-attached patches. My MUA\n> displays them fine and quotes them when I reply so I can easily review\n> them.\n\nYou strayed into tangent here. You said you do not have a\nproblem with non base64 attachments. I would like to know if\nyou have or do not have problem with base64 ones, as that is\nwhat indicates your opinion on making --attach unconditionally\ndo base64 which was the suggestion made in the thread.\n"},{"id":"40644","messageId":"Pine.LNX.4.64.0704280452150.12006@racer.site","threadId":"7870","inReplyTo":"d51pzpqo.fsf@cante.net","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-28T02:53:40Z","receivedAt":"2007-04-28T02:53:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Apr 2007, Jari Aalto wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Fri, 27 Apr 2007, Jari Aalto wrote:\n> >\n> >> FEAURE REQUEST\n> >> --------------\n> >> \n> >> Add sme option to git-format-path to encode thae patch content \n> >> (MIME/base64)\n> >\n> > [...]\n> >\n> > Having said that, I think that you can actually teach every mail app \n> > (except maybe web-based ones) to respect formatting, including white \n> > space.\n> \n> I hope the development team considers this. There is another uses case\n> that I can think of too:\n> \n> - Sending non us-ascii patches (different langauge)\n> \n> For documentation or code (Java/XML allows UTF-8). \n\nThat is no counterargument. I.e. it does not hold through basic scrutiny.\n\nCiao,\nDscho\n"},{"id":"40757","messageId":"873b2ho73n.wl%cworth@cworth.org","threadId":"7870","inReplyTo":"7vps5pl3jl.fsf@assigned-by-dhcp.cox.net","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-30T22:00:44Z","receivedAt":"2007-04-30T22:00:44Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 27 Apr 2007 17:56:46 -0700, Junio C Hamano wrote:\n> You strayed into tangent here. You said you do not have a\n> problem with non base64 attachments.\n\nYes, sorry for that.\n\n> I would like to know if\n> you have or do not have problem with base64 ones, as that is\n> what indicates your opinion on making --attach unconditionally\n> do base64 which was the suggestion made in the thread.\n\nI definitely have a problem with base64-encoded patches.\n\nMy MUA does much of exactly what I want with text attachments, (and\nstuff I thought most any MUA would do). Specifically, it always\ndisplays text attachments immediately following the message body\nitself. And it also quotes text attachments when I reply.\n\nSo, for me, a text attachment is almost identical in usability to an\ninline patch. And in some ways, it's even more usable. Since my MUA\nknows about the boundaries of each attachment, then if there are multiple\npatches, I can operate on any one individually (saving or organizing,\nor whatever), or even \"reply to\" an individual attachment by quoting\nonly that one.\n\nAnd my MUA does all that even if the text attachment comes with an\n\"attachment\" disposition instead of an \"inline\" disposition. And I\ncan't imagine why any MUA would not immediately display a text\nattachment, (unless as Linus suggests, it's to encourage user's to get\nbetter exercise by clicking more).\n\n*And* I think my MUA even does all that even if the attachment comes\nbase64-encoded. But in spite of that, I still am not happy to ever\nreceive a base64-encoded patch. Because I use things other than my MUA\nto look at my mail, (for example, I use grep and sometimes other\nindexing tools over my mail, and the base64 encoding ruins them).\n\nSo, that's where my preference comes for not wanting base64 encoding,\n(even when patches come attached but not inline).\n\n-Carl\n"},{"id":"40758","messageId":"871wi1o733.wl%cworth@cworth.org","threadId":"7870","inReplyTo":"alpine.LFD.0.98.0704271719240.9964@woody.linux-foundation.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-30T22:01:04Z","receivedAt":"2007-04-30T22:01:04Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 27 Apr 2007 17:20:48 -0700 (PDT), Linus Torvalds wrote:\n> Why would it be?\n>\n> Maybe for small projects with strictly linear development, but I get a\n> _lot_ of patch-series where the patches are independent of each other.\n> Andrew's patch-series are one example, but so is a lot of the \"trivial\n> tree\" patch-series too.\n\nAh. So here we were just using different definitions of \"patch\nseries\". I was using it the sense of a series of patches that were\nstrongly dependent. I definitely agree with you that independent\npatches belong in separate email messages. No doubt about that.\n\n-Carl\n\n"},{"id":"40759","messageId":"7vtzuxbj5h.fsf@assigned-by-dhcp.cox.net","threadId":"7870","inReplyTo":"873b2ho73n.wl%cworth@cworth.org","subject":"Re: FEATURE REQUEST: git-format-path: Add option to encode patch content","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-30T22:18:50Z","receivedAt":"2007-04-30T22:18:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> On Fri, 27 Apr 2007 17:56:46 -0700, Junio C Hamano wrote:\n>> ...\n>> I would like to know if\n>> you have or do not have problem with base64 ones, as that is\n>> what indicates your opinion on making --attach unconditionally\n>> do base64 which was the suggestion made in the thread.\n>\n> I definitely have a problem with base64-encoded patches.\n\nThanks, and I agree with everything you said why base64 is\ninconvenient. So _if_ somebody does an enhancement to do\nbase64, it needs to be a separate option.\n\nHonestly speaking, though, I think that kind of \"attachment\"\nshould be left to MUA, not format-patch. If somebody knows his\nMUA has a tendency to corrupt in-line text, tell the MUA to\nattach the format-patch output stored in the filesystem as an\napplication/octet-stream attachment. MUA may or may not do\nbase64 or QP but at that point the only thing the user cares\nabout is a byte-for-byte faithful reproduction at the\nrecipient's end, and he does not worry a whit about\nreadability), so either base64 or QP would suffice. And the\nformat-patch does not have to care.\n"}]}