{"thread":{"id":"19462","subject":"[PATCH 0/2] StGit patch series import","startedAt":"2009-05-24T07:19:16Z","lastAt":"2009-05-25T07:19:30Z","messageCount":14,"participants":["Giuseppe Bilotta","Junio C Hamano","Sverre Rabbelier"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"114547","messageId":"1243149558-17160-1-git-send-email-giuseppe.bilotta@gmail.com","threadId":"19462","inReplyTo":null,"subject":"[PATCH 0/2] StGit patch series import","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-05-24T07:19:16Z","receivedAt":"2009-05-24T07:19:16Z","isPatch":true,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"This small patch series implements support for Stacked Git patch\nseries import.\n\nThe first commit adds support for StGit patches to mailinfo, which is\nrequired because StGit's default export template puts the From: line\nbetween the subject and the body.\n\nThe second commit makes git-am autodetect an StGit patch series index\n(when it's the only file passed to it) and proceeds to import the\npatches indicated in the series.\n\nGiuseppe Bilotta (2):\n mailinfo: handle StGit patches\n git-am: support StGit patch series\n\n builtin-mailinfo.c | 18 ++++++++++++++++++\n git-am.sh | 22 ++++++++++++++++++++++\n 2 files changed, 40 insertions(+), 0 deletions(-)\n"},{"id":"114595","messageId":"7voctirzu6.fsf@alter.siamese.dyndns.org","threadId":"19462","inReplyTo":"1243149558-17160-1-git-send-email-giuseppe.bilotta@gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-24T20:49:21Z","receivedAt":"2009-05-24T20:49:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Giuseppe Bilotta writes:\n\n> This small patch series implements support for Stacked Git patch\n> series import.\n>\n> The first commit adds support for StGit patches to mailinfo, which is\n> required because StGit's default export template puts the From: line\n> between the subject and the body.\n\nThis problem description makes it sound as if we always expect From: to\ncome before Subject: in the mailbox, and reject the input if they come in\na different order, which would be a bug. Fixing it would not be limited\nto supporting StGIT generated patch email.\n\nBut a quick glance at the actual patch makes me suspect that is not what\nyou are doing. You are feeding something that is not a mailbox at all to\nthe mailinfo and _unconditionally_ extract the information according to\nStGIT rules.\n\nThat's a bad taste.\n\nAt least, add a \"this is not a mailbox, but is a StGIT formatted file, so\nplease extract info according to the StGIT rule, not the mailbox rule\"\noption, and\n\n (1) have a parameter to mailinfo() to trigger your new codepath only\n when the option is given; or\n\n (2) have a separate function \"stgitinfo()\" not \"mailinfo()\" that perhaps\n largely share the logic with the original \"mailinfo()\" function, and\n call that when the option is given; or even\n\n (3) have a separate _program_ that knows how to extract information from\n such an input file;\n\nso that normal mailinfo invocation does not mishandle input that is _not_\nStGIT output.\n\n> The second commit makes git-am autodetect an StGit patch series index\n> (when it's the only file passed to it) and proceeds to import the\n> patches indicated in the series.\n\nAnd that change would be a good place to decide to pass that \"This is not\na mailbox but is a StGIT output\" option to the updated mailinfo program\n(or the new \"stgitinfo\" program).\n\nWhat is the larger picture workflow that this new feature is expected to\nhelp? A project takes patches not in e-mail form but in a directory full\nof files uploaded via scp/sftp with the StGIT series file and individual\nStGIT patches that are pointed by the series file contained within?\n\nI do not use StGIT anymore, so I do not remember how flexible its export\ntemplate mechanism is, nor how widely people use non-default templates,\nbut I have wonder about two and half things.\n\n - I am assuming that your patch won't be able to read the StGIT output if\n the uploader used non-default export template, so such a project needs\n to ask the uploaders to use the default template.\n\n If that is the case, why not ask them to use a custom template that\n generates one single valid mailbox that stores the patches in the right\n order? That can be processed with stock \"git am\"; in addition, the\n output can be fed not just to \"git\". Any other SCM that can work with\n e-mail based patchflow can use it.\n\n - Such a project can allow users to use random export templates as long\n as the template used to export the series is indentifiable (perhaps by\n including that template itself in the upload). Your mailinfo patch\n needs to be extended to reverse what the export template did, and it\n really shouldn't be in the normal mailinfo() codepath. The right\n approach would become something like (3) above, i.e. separate\n \"StGITinfo\" program called from \"git am\" if that is what you shoot for.\n\n - If StGIT is used by the project to such an extent to allow series\n directory upload, shouldn't the receiving end be also using StGIT to\n import the series, instead of running \"git am\" anyway?\n"},{"id":"114600","messageId":"cb7bb73a0905241443m6b5d6ba4vab438c856e47a947@mail.gmail.com","threadId":"19462","inReplyTo":"7voctirzu6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-05-24T21:43:40Z","receivedAt":"2009-05-24T21:43:40Z","isPatch":true,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Sun, May 24, 2009 at 10:49 PM, Junio C Hamano wrote:\n> Giuseppe Bilotta writes:\n>\n>> This small patch series implements support for Stacked Git patch\n>> series import.\n>>\n>> The first commit adds support for StGit patches to mailinfo, which is\n>> required because StGit's default export template puts the From: line\n>> between the subject and the body.\n>\n> This problem description makes it sound as if we always expect From: to\n> come before Subject: in the mailbox, and reject the input if they come in\n> a different order, which would be a bug.  Fixing it would not be limited\n> to supporting StGIT generated patch email.\n\nI should probably have added the information that the subject in StGIT\npatches is _not_ prefixed by 'Subject: ', it's just placed as-is. So\nit's not a matter of ordering.\n\n> But a quick glance at the actual patch makes me suspect that is not what\n> you are doing.  You are feeding something that is not a mailbox at all to\n> the mailinfo and _unconditionally_ extract the information according to\n> StGIT rules.\n>\n> That's a bad taste.\n>\n> At least, add a \"this is not a mailbox, but is a StGIT formatted file, so\n> please extract info according to the StGIT rule, not the mailbox rule\"\n> option, and\n>\n>  (1) have a parameter to mailinfo() to trigger your new codepath only\n>      when the option is given; or\n\n[snip]\n\n> so that normal mailinfo invocation does not mishandle input that is _not_\n> StGIT output.\n\nWhen I started coding this feature, I had some thoughts about this,\nand my initial choice was to implement it following the suggestions\nyou mentioned. However, after thinking about it a while I realized the\nfollowing: the new code-path is taken only if the file does not start\nwith (what looks like) a mail header. If the file is not a StGIT patch\nexported with the default template, the info extraction will fail\nsomewhere else (e.g. because no author or no diff is found).\n\nSo in the end I decided to go the much simpler way of the patches I sent.\n\n>> The second commit makes git-am autodetect an StGit patch series index\n>> (when it's the only file passed to it) and proceeds to import the\n>> patches indicated in the series.\n>\n> And that change would be a good place to decide to pass that \"This is not\n> a mailbox but is a StGIT output\" option to the updated mailinfo program\n> (or the new \"stgitinfo\" program).\n\nThat was my initial thought too, but then I realized that having the\n'heuristics' (although a very braindead one) in mailinfo makes more\nsense because otherwise StGIT patch autodetection would only work when\napplying a whole series, and not when applying a single (or a few)\npatches.\n\n> What is the larger picture workflow that this new feature is expected to\n> help?  A project takes patches not in e-mail form but in a directory full\n> of files uploaded via scp/sftp with the StGIT series file and individual\n> StGIT patches that are pointed by the series file contained within?\n\nSort of. The specifics is that there's a guy developing a DIB engine\nfor Wine and he's using StGIT to handle the patches on top of the\nofficial Wine git tree. Periodically he zips the patch series\n(index+patches) and attaches it to the relevant bugzilla entry.\n\n> I do not use StGIT anymore, so I do not remember how flexible its export\n> template mechanism is, nor how widely people use non-default templates,\n> but I have wonder about two and half things.\n>\n>  - I am assuming that your patch won't be able to read the StGIT output if\n>   the uploader used non-default export template, so such a project needs\n>   to ask the uploaders to use the default template.\n\nWell, in the use-case that triggered my need for the StGIT import,\nthat was the case already.\n\n>   If that is the case, why not ask them to use a custom template that\n>   generates one single valid mailbox that stores the patches in the right\n>   order?  That can be processed with stock \"git am\"; in addition, the\n>   output can be fed not just to \"git\".  Any other SCM that can work with\n>   e-mail based patchflow can use it.\n\nWe have actually asked him to use plain git instead of StGIT, but he's\nmore comfortable with the latter. We could ask him to fix the header,\nyes. I'm not too optimistic about a positive response.\n\n>  - Such a project can allow users to use random export templates as long\n>   as the template used to export the series is indentifiable (perhaps by\n>   including that template itself in the upload).  Your mailinfo patch\n>   needs to be extended to reverse what the export template did, and it\n>   really shouldn't be in the normal mailinfo() codepath.  The right\n>   approach would become something like (3) above, i.e. separate\n>   \"StGITinfo\" program called from \"git am\" if that is what you shoot for.\n\nOh, in my grand plan of things git am should be able to handle all\nkind of foreign patches (svn and the patches sent by Bram Moolenar\nuses for vim being top candidates). (Of course it would be appropriate\nto rename it to something else then.) Sadly, I quickly discovered that\nmy file and string manipulation-fu in C is not really what I would\ncall 'strong'.\n\n(And since I needed it fast, I went the easy rather than the formally\ncorrect way.)\n\n>  - If StGIT is used by the project to such an extent to allow series\n>   directory upload, shouldn't the receiving end be also using StGIT to\n>   import the series, instead of running \"git am\" anyway?\n\nAs I mentioned, Wine uses plain git, and we've tried asking this\n(non-core) developer to expose a standard git tree. But he finds StGIT\nmuch more comfortable for the task.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"114601","messageId":"fabb9a1e0905241455j7045a920m11e7dcd6a92dd80a@mail.gmail.com","threadId":"19462","inReplyTo":"cb7bb73a0905241443m6b5d6ba4vab438c856e47a947@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-05-24T21:55:32Z","receivedAt":"2009-05-24T21:55:32Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, May 24, 2009 at 23:43, Giuseppe Bilotta\n wrote:\n> As I mentioned, Wine uses plain git, and we've tried asking this\n> (non-core) developer to expose a standard git tree. But he finds StGIT\n> much more comfortable for the task.\n\nSilly question, doesn't StGit have an export option? Methinks if all\nthe developer has to do is run 'stgit export' and then attach those\npatches instead of the raw patches, it'd be really lame of him not to\ndo at least that?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"114602","messageId":"7vfxeurwh0.fsf@alter.siamese.dyndns.org","threadId":"19462","inReplyTo":"cb7bb73a0905241443m6b5d6ba4vab438c856e47a947@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-24T22:02:03Z","receivedAt":"2009-05-24T22:02:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Giuseppe Bilotta writes:\n\n> That was my initial thought too, but then I realized that having the\n> 'heuristics' (although a very braindead one) in mailinfo makes more\n> sense because otherwise StGIT patch autodetection would only work when\n> applying a whole series, and not when applying a single (or a few)\n> patches.\n\nThe above is very selfish---what if somebody else wanted to add a feature\nto grok a non-mailbox input to the same codepath, and it is not a StGIT\npatch?\n\nThat is what I called \"bad taste\".\n\nThe same comment may apply to the rest of your response. \"This hack is\ngood enough for _my_ use case; I do not care if my change makes life\nharder for others to build on top of my patch\" is not what I want to see.\n"},{"id":"114603","messageId":"cb7bb73a0905241504s7d531f0lb5908a499d4345f@mail.gmail.com","threadId":"19462","inReplyTo":"fabb9a1e0905241455j7045a920m11e7dcd6a92dd80a@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-05-24T22:04:31Z","receivedAt":"2009-05-24T22:04:31Z","isPatch":true,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Sun, May 24, 2009 at 11:55 PM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Sun, May 24, 2009 at 23:43, Giuseppe Bilotta\n> wrote:\n>> As I mentioned, Wine uses plain git, and we've tried asking this\n>> (non-core) developer to expose a standard git tree. But he finds StGIT\n>> much more comfortable for the task.\n>\n> Silly question, doesn't StGit have an export option? Methinks if all\n> the developer has to do is run 'stgit export' and then attach those\n> patches instead of the raw patches, it'd be really lame of him not to\n> do at least that?\n\nThat's what he does. The problem is that StGIT export exports a patch\nseries using a given template which (by default) is not in mailbox\nformat.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"114604","messageId":"fabb9a1e0905241505t76bc18fm64547b65643f2273@mail.gmail.com","threadId":"19462","inReplyTo":"cb7bb73a0905241504s7d531f0lb5908a499d4345f@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-05-24T22:05:58Z","receivedAt":"2009-05-24T22:05:58Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, May 25, 2009 at 00:04, Giuseppe Bilotta\n wrote:\n> That's what he does. The problem is that StGIT export exports a patch\n> series using a given template which (by default) is not in mailbox\n> format.\n\nAh, so you're patching the wrong command then :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"114605","messageId":"cb7bb73a0905241518l43048416i34cb905c143c63e0@mail.gmail.com","threadId":"19462","inReplyTo":"7vfxeurwh0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-05-24T22:18:25Z","receivedAt":"2009-05-24T22:18:25Z","isPatch":true,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Mon, May 25, 2009 at 12:02 AM, Junio C Hamano wrote:\n> Giuseppe Bilotta writes:\n>\n>> That was my initial thought too, but then I realized that having the\n>> 'heuristics' (although a very braindead one) in mailinfo makes more\n>> sense because otherwise StGIT patch autodetection would only work when\n>> applying a whole series, and not when applying a single (or a few)\n>> patches.\n>\n> The above is very selfish---what if somebody else wanted to add a feature\n> to grok a non-mailbox input to the same codepath, and it is not a StGIT\n> patch?\n>\n> That is what I called \"bad taste\".\n>\n> The same comment may apply to the rest of your response.  \"This hack is\n> good enough for _my_ use case; I do not care if my change makes life\n> harder for others to build on top of my patch\" is not what I want to see.\n\nSorry, that's totally not the idea was trying to convey. In fact, just\nafter sending the email I went back to the code to look for a better\nsolution (I should have probably also made the first try a RFC).\n\nI did feel it was necessary to explain the reasons for the simplicity\nof the patches, especially since it gave me the chance to raises some\npoints that I thought were worth discussing, such as the matter of\nwhere to place patch type autodetection.\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"114606","messageId":"fabb9a1e0905241528r7b5102b0w5d064727125654d@mail.gmail.com","threadId":"19462","inReplyTo":"cb7bb73a0905241518l43048416i34cb905c143c63e0@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-05-24T22:28:36Z","receivedAt":"2009-05-24T22:28:36Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, May 25, 2009 at 00:18, Giuseppe Bilotta\n wrote:\n> Sorry, that's totally not the idea was trying to convey. In fact, just\n> after sending the email I went back to the code to look for a better\n> solution (I should have probably also made the first try a RFC).\n\nPerhaps a more elegant solution is a script that munges a hg/stgit/svn\npatch into a mailbox format before feeding it to git-am? 'git munge'\nis free :D\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"114608","messageId":"cb7bb73a0905241553i2cf2c246ycd0b5466e60c8de8@mail.gmail.com","threadId":"19462","inReplyTo":"fabb9a1e0905241528r7b5102b0w5d064727125654d@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-05-24T22:53:20Z","receivedAt":"2009-05-24T22:53:20Z","isPatch":true,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Mon, May 25, 2009 at 12:28 AM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Mon, May 25, 2009 at 00:18, Giuseppe Bilotta\n> wrote:\n>> Sorry, that's totally not the idea was trying to convey. In fact, just\n>> after sending the email I went back to the code to look for a better\n>> solution (I should have probably also made the first try a RFC).\n>\n> Perhaps a more elegant solution is a script that munges a hg/stgit/svn\n> patch into a mailbox format before feeding it to git-am? 'git munge'\n> is free :D\n\nThis is an interesting solution. And git-am could call git-munge\nautomatically before feeding the patches to mailinfo, replacing\n git mailinfo $keep $utf8 \"$dotest/msg\" \"$dotest/patch\" \\\n <\"$dotest/$msgnum\" >\"$dotest/info\"\nwith\n git munge \"$dotest/$msgnum\" | git mailinfo etc\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"114609","messageId":"fabb9a1e0905241557l403037f6p7c1df1f587cb9cf7@mail.gmail.com","threadId":"19462","inReplyTo":"cb7bb73a0905241553i2cf2c246ycd0b5466e60c8de8@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-05-24T22:57:44Z","receivedAt":"2009-05-24T22:57:44Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, May 25, 2009 at 00:53, Giuseppe Bilotta\n wrote:\n> This is an interesting solution. And git-am could call git-munge\n> automatically before feeding the patches to mailinfo, replacing\n>  git mailinfo $keep $utf8 \"$dotest/msg\" \"$dotest/patch\" \\\n>      <\"$dotest/$msgnum\" >\"$dotest/info\"\n> with\n>  git munge \"$dotest/$msgnum\" | git mailinfo etc\n\nI was thinking the other way around, so that 'git am' doesn't need to\nbe modified.\n\nBehind the scenes, git munge \"$dotest/$msgnum\" does something like:\n1. munge the file so that it's in the appropriate format\n2. dispatch to 'git am' with the munged file\n3. profit\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"114610","messageId":"cb7bb73a0905241603r4949abb5g1a9e861aba40c6fe@mail.gmail.com","threadId":"19462","inReplyTo":"fabb9a1e0905241557l403037f6p7c1df1f587cb9cf7@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-05-24T23:03:38Z","receivedAt":"2009-05-24T23:03:38Z","isPatch":true,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Mon, May 25, 2009 at 12:57 AM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Mon, May 25, 2009 at 00:53, Giuseppe Bilotta\n> wrote:\n>> This is an interesting solution. And git-am could call git-munge\n>> automatically before feeding the patches to mailinfo, replacing\n>>  git mailinfo $keep $utf8 \"$dotest/msg\" \"$dotest/patch\" \\\n>>      <\"$dotest/$msgnum\" >\"$dotest/info\"\n>> with\n>>  git munge \"$dotest/$msgnum\" | git mailinfo etc\n>\n> I was thinking the other way around, so that 'git am' doesn't need to\n> be modified.\n>\n> Behind the scenes, git munge \"$dotest/$msgnum\" does something like:\n> 1. munge the file so that it's in the appropriate format\n> 2. dispatch to 'git am' with the munged file\n> 3. profit\n\nBut then the name munge would not be descriptive of what the command\ndoes. If git am is to be left untouched, I would rather then have\nsomething like git import-patches that accepts patches in 'any'\nformat, expanding StGIT series into the respective patches and\ntransforming everything into mbox format, invoking am on the final\nresult. But I see no particular reason why git-am shouldn't be able to\nhandle all this by itself\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"114624","messageId":"7vocthy9df.fsf@alter.siamese.dyndns.org","threadId":"19462","inReplyTo":"cb7bb73a0905241603r4949abb5g1a9e861aba40c6fe@mail.gmail.com","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-25T06:39:08Z","receivedAt":"2009-05-25T06:39:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Giuseppe Bilotta writes:\n\n> But then the name munge would not be descriptive of what the command\n> does. If git am is to be left untouched, I would rather then have\n> something like git import-patches that accepts patches in 'any'\n> format,...\n\nThere is no need to introduce any new program, I think.\n\nNobody is against your teaching the \"git am\" callchain to accept things\nother than Berkeley mbox. \"git am\" is \"import-patches\" in that sense\nalready.\n\nYou can add a conditional (perhaps triggered by a \"the patches are in this\nformat\" command line option) to \"git am\" to alter the way it splits the\ninput into individual pieces of e-mail, named 0001, 0002, 0003, ..., and\nleaves the total number of message in $dotest/last.\n\nCurrently we call \"git-mailsplit\" to do all of that; your new conditional\nwill take StGIT export, and instead of calling \"git-mailsplit\", read the\nseries file and process individual patch files into 0001, 0002,... that\nare in proper mbox format (i.e. you would need to fix the \"Subject: \" less\ntitle line when you do this), and leave the total number of patches in\n$dotest/last file.\n\nWith that change, the main loop that iterates 'while test \"$this\" -le\n\"$last\"' does not have to change, right?\n\nWe could for example add RMAIL format support in the same way.\n"},{"id":"114627","messageId":"cb7bb73a0905250019y12e3747brff3c0b6a6523c41a@mail.gmail.com","threadId":"19462","inReplyTo":"7vocthy9df.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] StGit patch series import","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-05-25T07:19:30Z","receivedAt":"2009-05-25T07:19:30Z","isPatch":true,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Mon, May 25, 2009 at 8:39 AM, Junio C Hamano wrote:\n> Giuseppe Bilotta writes:\n>\n>> But then the name munge would not be descriptive of what the command\n>> does. If git am is to be left untouched, I would rather then have\n>> something like git import-patches that accepts patches in 'any'\n>> format,...\n>\n> There is no need to introduce any new program, I think.\n\nI'm not so sure about this, see below.\n\n> Nobody is against your teaching the \"git am\" callchain to accept things\n> other than Berkeley mbox.  \"git am\" is \"import-patches\" in that sense\n> already.\n\nI thought as much 8-)\n\n> You can add a conditional (perhaps triggered by a \"the patches are in this\n> format\" command line option) to \"git am\"\n\nI'd rather have autodetection than command line options, at least as\nlong as it can be done reliably enough.\n\n> to alter the way it splits the\n> input into individual pieces of e-mail, named 0001, 0002, 0003, ..., and\n> leaves the total number of message in $dotest/last.\n> Currently we call \"git-mailsplit\" to do all of that; your new conditional\n> will take StGIT export, and instead of calling \"git-mailsplit\", read the\n> series file and process individual patch files into 0001, 0002,... that\n> are in proper mbox format (i.e. you would need to fix the \"Subject: \" less\n> title line when you do this), and leave the total number of patches in\n> $dotest/last file.\n\nHm. It does make sense to have mail conversion at 'mailsplit' time.\nThe preprocessing would (1) explode any series, if present (2) convert\nthe patch from whatever format they are in into mbox format (3) put\nthem in place. (1) is what my git am patch does, so what we need is\nessentially (2). For efficiency we could assume that the user does not\npass patches of different formats to us, so we peek at the first patch\nand treat all of them as that kind of patch.\n\nI do suspect that patch format conversion _does_ require an additional\nprogram, in the sense that not doing so would make the git-am script\ngrow, and I'm not sure it would be very efficient. Is core git C+sh\nonly or can we rely on some Perl stuff? It'd probably be more\nappropriate for this kind of job.\n\n> With that change, the main loop that iterates 'while test \"$this\" -le\n> \"$last\"' does not have to change, right?\n\nWell, my proposed change git-munge | git-mailinfo would not be that\nbig of a change, but it does make sense to make the conversion early\non, as I mentioned above. It also makes it easier to debug the\nconversion, as the result is kept in the dotest directory.\n\n> We could for example add RMAIL format support in the same way.\n\nNo idea what that is.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"}]}