{"thread":{"id":"12305","subject":"git-email automatic --to detection?","startedAt":"2008-02-24T22:29:56Z","lastAt":"2008-02-26T17:44:42Z","messageCount":18,"participants":["John Goerzen","Paolo Ciarrocchi","Miklos Vajna","Jeff King","Matthieu Moy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"69829","messageId":"slrnfs3rv4.aqm.jgoerzen@katherina.lan.complete.org","threadId":"12305","inReplyTo":null,"subject":"git-email automatic --to detection?","fromName":"John Goerzen","fromEmail":"jgoerzen@complete.org","sentAt":"2008-02-24T22:29:56Z","receivedAt":"2008-02-24T22:29:56Z","isPatch":false,"sender":{"key":"jgoerzen@complete.org","avatar":null},"body":"One of my favorite features of Darcs is that users can submit patches\nby typing:\n\n darcs send -a\n\nThis will look at the repo the local copy was cloned from, find all\nlocal changesets that aren't on the remote, and email off a set of\npatches to the remote maintainer. It finds the email address to send\nto by looking at _darcs/prefs/email *on the remote*, which is roughly\nthe same as setting an option in .git/config.\n\nThere are a couple of nice things about this:\n\n1) Patch submitters don't have to keep track of where to send patches\nfor each project they work on\n\n2) Potential submitters don't have to be notified if the submission\naddress changes\n\nAs far as I can tell from looking at git-send-email(1),\ngit-format-patch(1), and git-config(1), git doesn't have this\ncapability. Is that correct? If so, is it possible to add something\nlike this? Would it also be possible to unify git-format-patch and\ngit-send-email into a single command that generates and sends the patch(es)?\n\nThanks,\n\n-- John\n"},{"id":"69831","messageId":"4d8e3fd30802241456l6c02a040te21643c830cf0e46@mail.gmail.com","threadId":"12305","inReplyTo":"slrnfs3rv4.aqm.jgoerzen@katherina.lan.complete.org","subject":"Re: git-email automatic --to detection?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-02-24T22:56:03Z","receivedAt":"2008-02-24T22:56:03Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 2/25/08, John Goerzen > Would it also be possible to unify\ngit-format-patch and\n> git-send-email into a single command that generates and sends the patch(es)?\n\nI can't think of how to unify the commands from the ui point of view.\nWhat do you suggest?\n\nHowever, i like the idea of a --send commad line option to\ngit-format-patch that calls git-send-email to create and send the\npatch series.\n\nCiao,\n--\nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"69887","messageId":"20080225143959.GS31441@genesis.frugalware.org","threadId":"12305","inReplyTo":"slrnfs3rv4.aqm.jgoerzen@katherina.lan.complete.org","subject":"Re: git-email automatic --to detection?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-02-25T14:39:59Z","receivedAt":"2008-02-25T14:39:59Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sun, Feb 24, 2008 at 04:29:56PM -0600, John Goerzen wrote:\n> As far as I can tell from looking at git-send-email(1),\n> git-format-patch(1), and git-config(1), git doesn't have this\n> capability. Is that correct?\n\ni don't think so. what about git config sendemail.to?\n\n- VMiklos\n"},{"id":"69889","messageId":"slrnfs5me6.lhp.jgoerzen@katherina.lan.complete.org","threadId":"12305","inReplyTo":"4d8e3fd30802241456l6c02a040te21643c830cf0e46@mail.gmail.com","subject":"Re: git-email automatic --to detection?","fromName":"John Goerzen","fromEmail":"jgoerzen@complete.org","sentAt":"2008-02-25T15:07:50Z","receivedAt":"2008-02-25T15:07:50Z","isPatch":false,"sender":{"key":"jgoerzen@complete.org","avatar":null},"body":"On 2008-02-24, Paolo Ciarrocchi wrote:\n> On 2/25/08, John Goerzen > Would it also be possible to unify\n> git-format-patch and\n>> git-send-email into a single command that generates and sends the patch(es)?\n>\n> I can't think of how to unify the commands from the ui point of view.\n> What do you suggest?\n>\n> However, i like the idea of a --send commad line option to\n> git-format-patch that calls git-send-email to create and send the\n> patch series.\n\nThat sounds reasonable to me.\n\nI'm all in favor of less typing, so git-email sounds even better :-)\n\n-- John\n"},{"id":"69890","messageId":"200802250908.21182.jgoerzen@complete.org","threadId":"12305","inReplyTo":"20080225143959.GS31441@genesis.frugalware.org","subject":"Re: git-email automatic --to detection?","fromName":"John Goerzen","fromEmail":"jgoerzen@complete.org","sentAt":"2008-02-25T15:08:20Z","receivedAt":"2008-02-25T15:08:20Z","isPatch":false,"sender":{"key":"jgoerzen@complete.org","avatar":null},"body":"On Mon February 25 2008 8:39:59 am Miklos Vajna wrote:\n> On Sun, Feb 24, 2008 at 04:29:56PM -0600, John Goerzen \n wrote:\n> > As far as I can tell from looking at git-send-email(1),\n> > git-format-patch(1), and git-config(1), git doesn't have this\n> > capability. Is that correct?\n>\n> i don't think so. what about git config sendemail.to?\n\nBut that must be applied locally. It is not pulling that down from the \nremote repo before the send, which is the point of all this.\n\n\n>\n> - VMiklos\n"},{"id":"69896","messageId":"20080225183413.GA15131@sigill.intra.peff.net","threadId":"12305","inReplyTo":"slrnfs3rv4.aqm.jgoerzen@katherina.lan.complete.org","subject":"Re: git-email automatic --to detection?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-25T18:34:14Z","receivedAt":"2008-02-25T18:34:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 24, 2008 at 04:29:56PM -0600, John Goerzen wrote:\n\n> This will look at the repo the local copy was cloned from, find all\n> local changesets that aren't on the remote, and email off a set of\n> patches to the remote maintainer. It finds the email address to send\n> to by looking at _darcs/prefs/email *on the remote*, which is roughly\n> the same as setting an option in .git/config.\n\nThere is not (currently) a way to read the remote config using the git\nprotocol. There was some discussion on a protocol extension a few months\nback to do so, but I don't recall whether any patches came out of it.\n\n> There are a couple of nice things about this:\n> \n> 1) Patch submitters don't have to keep track of where to send patches\n> for each project they work on\n> \n> 2) Potential submitters don't have to be notified if the submission\n> address changes\n\nThere was some discussion about this a while back for the kernel. Some\nrelevant points that I recall:\n\n - there's more than _one_ maintainer for the repo; in fact, who you\n email depends on what part of the code you are touching\n\n - this information could be shipped as part of the repo (i.e., under\n version control like the rest of the project, as it changes with the\n project)\n\n - this information can potentially be inferred from git shortlog\n and/or blame; this addresses the problem of data becoming stale\n\nSee this thread:\n\n http://mid.gmane.org/1187110824.32555.76.camel@localhost\n\n> As far as I can tell from looking at git-send-email(1),\n> git-format-patch(1), and git-config(1), git doesn't have this\n> capability. Is that correct? If so, is it possible to add something\n> like this? Would it also be possible to unify git-format-patch and\n> git-send-email into a single command that generates and sends the\n> patch(es)?\n\nYou could make a wrapper script around the two commands that pieces them\ntogether. Though I'm not sure how likely that would be to get accepted\nupstream; there are already complaints of too many commands, and this\none would likely be specific to your workflow (many of us have our own\nsuch wrapper scripts already).\n\n-Peff\n"},{"id":"69897","messageId":"20080225183547.GB15131@sigill.intra.peff.net","threadId":"12305","inReplyTo":"4d8e3fd30802241456l6c02a040te21643c830cf0e46@mail.gmail.com","subject":"Re: git-email automatic --to detection?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-25T18:35:48Z","receivedAt":"2008-02-25T18:35:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 25, 2008 at 02:26:03AM +0330, Paolo Ciarrocchi wrote:\n\n> I can't think of how to unify the commands from the ui point of view.\n> What do you suggest?\n> \n> However, i like the idea of a --send commad line option to\n> git-format-patch that calls git-send-email to create and send the\n> patch series.\n\nI think it makes sense the other way around: have git-send-email invoke\ngit-format-patch.\n\nMy reasoning is that git-send-email users almost always use\ngit-format-patch, but git-format-patch users frequently do not use\ngit-send-email.\n\n-Peff\n"},{"id":"69900","messageId":"4d8e3fd30802251056t626ff51dx8a6ea7a006222e72@mail.gmail.com","threadId":"12305","inReplyTo":"20080225183547.GB15131@sigill.intra.peff.net","subject":"Re: git-email automatic --to detection?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-02-25T18:56:18Z","receivedAt":"2008-02-25T18:56:18Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 2/25/08, Jeff King wrote:\n> On Mon, Feb 25, 2008 at 02:26:03AM +0330, Paolo Ciarrocchi wrote:\n>\n> > I can't think of how to unify the commands from the ui point of view.\n> > What do you suggest?\n> >\n> > However, i like the idea of a --send commad line option to\n> > git-format-patch that calls git-send-email to create and send the\n> > patch series.\n>\n> I think it makes sense the other way around: have git-send-email invoke\n> git-format-patch.\n>\n> My reasoning is that git-send-email users almost always use\n> git-format-patch, but git-format-patch users frequently do not use\n> git-send-email.\n\n\nthat's correct. I even like the idea of a single git email command.\nciao,\n--\nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"69902","messageId":"vpqoda43lva.fsf@bauges.imag.fr","threadId":"12305","inReplyTo":"20080225183413.GA15131@sigill.intra.peff.net","subject":"Re: git-email automatic --to detection?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-02-25T18:57:13Z","receivedAt":"2008-02-25T18:57:13Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jeff King writes:\n\n> - there's more than _one_ maintainer for the repo; in fact, who you\n> email depends on what part of the code you are touching\n\nYes, but a sane default address to send to can be given by the\nrepository you make your original clone from.\n\nThe really nice thing with the way darcs does it is that it makes it\nextremely easy for an occasional contribution. If the maintainer\nconfigured his stuff correctly, it's really \"darcs get; ... ; darcs\nrecord; darcs send\". git-send-email is nice, but harder to use for a\nfirst-timer.\n\n> - this information could be shipped as part of the repo (i.e., under\n> version control like the rest of the project, as it changes with the\n> project)\n\nTrue, but for the case of multiple maintainers, that would break\nmerging between maintainers on that particular part.\n\nYou can have a maintainer A advertizing for A@domain.com, and a\n\"sub-maintainer\" B advertizing for B@domain.com. If A merges from B,\nhe doesn't want his advertized adress to become the one of B.\n\n> - this information can potentially be inferred from git shortlog\n> and/or blame; this addresses the problem of data becoming stale\n\nYes and no. git@vger.kernel.org won't appear anywhere in these for\nexample.\n\n-- \nMatthieu\n"},{"id":"69906","messageId":"20080225191931.GA19666@sigill.intra.peff.net","threadId":"12305","inReplyTo":"vpqoda43lva.fsf@bauges.imag.fr","subject":"Re: git-email automatic --to detection?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-25T19:19:31Z","receivedAt":"2008-02-25T19:19:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 25, 2008 at 07:57:13PM +0100, Matthieu Moy wrote:\n\n> Yes, but a sane default address to send to can be given by the\n> repository you make your original clone from.\n>\n> The really nice thing with the way darcs does it is that it makes it\n> extremely easy for an occasional contribution. If the maintainer\n> configured his stuff correctly, it's really \"darcs get; ... ; darcs\n> record; darcs send\". git-send-email is nice, but harder to use for a\n> first-timer.\n\nI agree that this is useful, especially for smaller projects where it\nreally _is_ just one address.\n\n> > - this information could be shipped as part of the repo (i.e., under\n> > version control like the rest of the project, as it changes with the\n> > project)\n> \n> True, but for the case of multiple maintainers, that would break\n> merging between maintainers on that particular part.\n> \n> You can have a maintainer A advertizing for A@domain.com, and a\n> \"sub-maintainer\" B advertizing for B@domain.com. If A merges from B,\n> he doesn't want his advertized adress to become the one of B.\n\nI think there are advantages and drawbacks to both methods.\nVersion-controlled information is better for a project that has multiple\nofficial maintainers, and those maintainers want to submit a patch\nsaying \"and here's my contacat information.\" But it's worse for people\nwho are saying \"here's somebody else's repo with my patches, but email\nme about it\".\n\nWorse, you may want to do either in a particular repo, depending on what\nyour patches are. If I publish a repo with patches on top of git.git,\nthen you want to email me for patches specific to my repo, but probably\nthe regular git list and subsystem maintainers for patches that are\ngenerally applicable.\n\nSo I'm not sure you will be able to write a tool that will always just\ndo the right thing.\n\n> > - this information can potentially be inferred from git shortlog\n> > and/or blame; this addresses the problem of data becoming stale\n> \n> Yes and no. git@vger.kernel.org won't appear anywhere in these for\n> example.\n\nYes, there would need to be some tool that combines:\n - per-repo patch submitting policy (i.e., mail me because I am your\n upstream)\n - per-project patch submitting policy (i.e., mail git@vger for git\n patches)\n - per-patch policy (e.g., this patch touches foo.c: who is\n interested in foo.c?)\n\n-Peff\n"},{"id":"69911","messageId":"7vabloizt0.fsf@gitster.siamese.dyndns.org","threadId":"12305","inReplyTo":"20080225183413.GA15131@sigill.intra.peff.net","subject":"Re: git-email automatic --to detection?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-25T19:47:07Z","receivedAt":"2008-02-25T19:47:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> There was some discussion about this a while back for the kernel. Some\n> relevant points that I recall:\n>\n> - there's more than _one_ maintainer for the repo; in fact, who you\n> email depends on what part of the code you are touching\n>\n> - this information could be shipped as part of the repo (i.e., under\n> version control like the rest of the project, as it changes with the\n> project)\n>\n> - this information can potentially be inferred from git shortlog\n> and/or blame; this addresses the problem of data becoming stale\n>\n> See this thread:\n>\n> http://mid.gmane.org/1187110824.32555.76.camel@localhost\n\nThat matches my recollection, but I think the most important\npoint to take home from these points are that you cannot blindly\nsay that the tool can figure it out and do that for you. We\ncould probably have an automated way to scan shortlog and\nwhatnot and offer suggestions, but the final determination of\nthe recipient addresses needs to be done by the end user.\n\nWhich in short means README or Documentation/SubmittingPatches\nwould be the most appropriate place for that information.\n"},{"id":"69914","messageId":"slrnfs67lp.lsg.jgoerzen@katherina.lan.complete.org","threadId":"12305","inReplyTo":"vpqoda43lva.fsf@bauges.imag.fr","subject":"Re: git-email automatic --to detection?","fromName":"John Goerzen","fromEmail":"jgoerzen@complete.org","sentAt":"2008-02-25T20:02:01Z","receivedAt":"2008-02-25T20:02:01Z","isPatch":false,"sender":{"key":"jgoerzen@complete.org","avatar":null},"body":"On 2008-02-25, Matthieu Moy wrote:\n> You can have a maintainer A advertizing for A@domain.com, and a\n> \"sub-maintainer\" B advertizing for B@domain.com. If A merges from B,\n> he doesn't want his advertized adress to become the one of B.\n\nRight. That's why this would be a per-repo setting. It wouldn't be\npulled or cloned, just looked up when needed.\n\nI imagine that in gitese, this would mean that by default this would\nbe looked up in the repo that origin points to.\n"},{"id":"69922","messageId":"20080225205046.GX31441@genesis.frugalware.org","threadId":"12305","inReplyTo":"200802250908.21182.jgoerzen@complete.org","subject":"Re: git-email automatic --to detection?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-02-25T20:50:46Z","receivedAt":"2008-02-25T20:50:46Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Feb 25, 2008 at 09:08:20AM -0600, John Goerzen wrote:\n> But that must be applied locally. It is not pulling that down from the \n> remote repo before the send, which is the point of all this.\n\nright. this is a pro and a con: you can't run darcs send -a while you're\noffline but you can do a git format-patch while offline. and of course\n_once_ you have to configure sendemail.to manually.\n\n- VMiklos\n"},{"id":"69924","messageId":"20080225205505.GY31441@genesis.frugalware.org","threadId":"12305","inReplyTo":"vpqoda43lva.fsf@bauges.imag.fr","subject":"Re: git-email automatic --to detection?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-02-25T20:55:05Z","receivedAt":"2008-02-25T20:55:05Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Feb 25, 2008 at 07:57:13PM +0100, Matthieu Moy wrote:\n> The really nice thing with the way darcs does it is that it makes it\n> extremely easy for an occasional contribution. If the maintainer\n> configured his stuff correctly, it's really \"darcs get; ... ; darcs\n> record; darcs send\". git-send-email is nice, but harder to use for a\n> first-timer.\n\nthat's true, while the practice can be the opposite. darcs forces you to\nhave an smtpd on localhost, while git allows you to send the patch from\nyour mail client. this _is_ easier for people sometimes. (especially\nthese days when everybody blocks dhcp address ranges and an avarage user\ndoesn't configure a proxy smtpd on localhost usually i think.)\n\n- VMiklos\n"},{"id":"69971","messageId":"vpqve4c136b.fsf@bauges.imag.fr","threadId":"12305","inReplyTo":"slrnfs67lp.lsg.jgoerzen@katherina.lan.complete.org","subject":"Re: git-email automatic --to detection?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-02-26T09:23:56Z","receivedAt":"2008-02-26T09:23:56Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"John Goerzen writes:\n\n> On 2008-02-25, Matthieu Moy wrote:\n>> You can have a maintainer A advertizing for A@domain.com, and a\n>> \"sub-maintainer\" B advertizing for B@domain.com. If A merges from B,\n>> he doesn't want his advertized adress to become the one of B.\n>\n> Right. That's why this would be a per-repo setting. It wouldn't be\n> pulled or cloned, just looked up when needed.\n\nI think it should. Not versionned, but initialized by \"clone\" based on\nthe cloned repo.\n\nThe advantage of a clone-time initialization compared to a submit-time\nlook up is that the local user can very easily change the value\nmanually after a clone.\n\n-- \nMatthieu\n"},{"id":"69995","messageId":"slrnfs86qr.prc.jgoerzen@katherina.lan.complete.org","threadId":"12305","inReplyTo":"20080225205505.GY31441@genesis.frugalware.org","subject":"Re: git-email automatic --to detection?","fromName":"John Goerzen","fromEmail":"jgoerzen@complete.org","sentAt":"2008-02-26T13:59:55Z","receivedAt":"2008-02-26T13:59:55Z","isPatch":false,"sender":{"key":"jgoerzen@complete.org","avatar":null},"body":"On 2008-02-25, Miklos Vajna wrote:\n>> configured his stuff correctly, it's really \"darcs get; ... ; darcs\n>> record; darcs send\". git-send-email is nice, but harder to use for a\n>> first-timer.\n>\n> that's true, while the practice can be the opposite. darcs forces you to\n> have an smtpd on localhost, while git allows you to send the patch from\n> your mail client. this _is_ easier for people sometimes. (especially\n> these days when everybody blocks dhcp address ranges and an avarage user\n> doesn't configure a proxy smtpd on localhost usually i think.)\n\nActually, both can do both, right? darcs send -o will write the data\nto send out to a file on disk, and git-send-email will transmit the\nmessage. I don't so much care about the default as making it easy for\npeople that do have a local sendmail or smtpd or (ugh) MAPI client to\nsend patches automatically, if I tell them what flags to use.\n\n-- John\n"},{"id":"69996","messageId":"slrnfs878k.prc.jgoerzen@katherina.lan.complete.org","threadId":"12305","inReplyTo":"vpqve4c136b.fsf@bauges.imag.fr","subject":"Re: git-email automatic --to detection?","fromName":"John Goerzen","fromEmail":"jgoerzen@complete.org","sentAt":"2008-02-26T14:07:16Z","receivedAt":"2008-02-26T14:07:16Z","isPatch":false,"sender":{"key":"jgoerzen@complete.org","avatar":null},"body":"On 2008-02-26, Matthieu Moy wrote:\n>> Right. That's why this would be a per-repo setting. It wouldn't be\n>> pulled or cloned, just looked up when needed.\n>\n> I think it should. Not versionned, but initialized by \"clone\" based on\n> the cloned repo.\n\nThat would work.\n\n> The advantage of a clone-time initialization compared to a submit-time\n> look up is that the local user can very easily change the value\n> manually after a clone.\n\nYou could always make it work like this:\n\n* If an address is given on the command line, use that.\n\n* Otherwise, if an address is given in config, use that.\n\n* Otherwise, look up the address at the remote repo; if successful,\n use that.\n\n* Otherwise, prompt the user.\n\nThe advantage of this is that if the submission address changes (but\nthe remote repo URL hasn't), then patches can automatically go to the\nright place. Of course the disadvantage is that the config is not\ninitialized for offline mail queuing at clone time.\n\nI have generally found that not being able to queue patches offline\nisn't a big deal to me. Of course, someone could effectively do that\nalso be using format-patch as it is normally used now.\n\n-- John\n"},{"id":"70011","messageId":"20080226174442.GM31441@genesis.frugalware.org","threadId":"12305","inReplyTo":"slrnfs86qr.prc.jgoerzen@katherina.lan.complete.org","subject":"Re: git-email automatic --to detection?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-02-26T17:44:42Z","receivedAt":"2008-02-26T17:44:42Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Feb 26, 2008 at 07:59:55AM -0600, John Goerzen wrote:\n> Actually, both can do both, right?\n\nright. afaik no commands read the remote git config atm, but it might be\npossible.\n\n> darcs send -o will write the data\n> to send out to a file on disk, and git-send-email will transmit the\n> message.\n\ntrue. what annoyed me is that i needed net access to generate the file,\nie i was not able to do a 'darcs send -o file', copy the file to an usb\nstick and send it from some other box.\n\n> I don't so much care about the default as making it easy for\n> people that do have a local sendmail or smtpd or (ugh) MAPI client to\n> send patches automatically, if I tell them what flags to use.\n\nbut that's the case for git as well :) you should tell people (for\nexample): use \"git format-patch origin\"; send the created *.patch files\nand use \"git pull --rebase\" to avoid an unnecessary merge.\n\n- VMiklos\n"}]}