{"thread":{"id":"6410","subject":"[RFC] Add a suffix option to git-format-patch","startedAt":"2007-01-17T13:10:03Z","lastAt":"2007-01-19T10:11:14Z","messageCount":59,"participants":["Josh Boyer","Johannes Schindelin","David Kågedal","Horst H. von Brand","Andreas Ericsson","Junio C Hamano","Andy Whitcroft","Brian Gernhardt","Alex Riesen","Shawn O. Pearce","Alexandre Julliard","Lukas Sandström","Johannes Sixt","Martin Langhoff","Steven Grimm","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31879","messageId":"625fc13d0701170510x8883539g93f43d9ddffe56f0@mail.gmail.com","threadId":"6410","inReplyTo":null,"subject":"[RFC] Add a suffix option to git-format-patch","fromName":"Josh Boyer","fromEmail":"jwboyer@gmail.com","sentAt":"2007-01-17T13:10:03Z","receivedAt":"2007-01-17T13:10:03Z","isPatch":false,"sender":{"key":"jwboyer@gmail.com","avatar":null},"body":"Hi All,\n\nI use git quite a bit to track my changes and then use\ngit-format-patch to generate patches to send on to others. For the\nmost part, it works great but I find myself constantly doing:\n\nmv xxxx-foo.txt xxxx-foo.patch\n\nCould we add an option to git-format-patch to use \".patch\" as the file\nsuffix instead of \".txt\"? Something like the below?\n\njosh\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex a59b4ac..4eb2d32 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -217,6 +217,7 @@ static int git_format_config(const char *var,\nconst char *value)\n\n static FILE *realstdout = NULL;\n static const char *output_directory = NULL;\n+static int psuffix = 0;\n\n static void reopen_stdout(struct commit *commit, int nr, int keep_subject)\n {\n@@ -265,7 +266,11 @@ static void reopen_stdout(struct commit *commit,\nint nr, int keep_subject)\n \t\twhile (filename[len - 1] == '.' || filename[len - 1] == '-')\n \t\t\tlen--;\n \t}\n-\tstrcpy(filename + len, \".txt\");\n+\n+\tif (psuffix)\n+\t\tstrcpy(filename + len, \".patch\");\n+\telse\n+\t\tstrcpy(filename + len, \".txt\");\n \tfprintf(realstdout, \"%s\\n\", filename);\n \tfreopen(filename, \"w\", stdout);\n }\n@@ -436,6 +441,8 @@ int cmd_format_patch(int argc, const char **argv,\nconst char *prefix)\n \t\t\t\tdie(\"Need a Message-Id for --in-reply-to\");\n \t\t\tin_reply_to = argv[i];\n \t\t}\n+\t\telse if (!strcmp(argv[i], \"--psuffix\"))\n+\t\t\tpsuffix = 1;\n \t\telse\n \t\t\targv[j++] = argv[i];\n \t}\n"},{"id":"31884","messageId":"Pine.LNX.4.63.0701171446410.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"625fc13d0701170510x8883539g93f43d9ddffe56f0@mail.gmail.com","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-17T13:49:50Z","receivedAt":"2007-01-17T13:49:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Jan 2007, Josh Boyer wrote:\n\n> Could we add an option to git-format-patch to use \".patch\" as the file\n> suffix instead of \".txt\"? Something like the below?\n> \n> diff --git a/builtin-log.c b/builtin-log.c\n> index a59b4ac..4eb2d32 100644\n> --- a/builtin-log.c\n> +++ b/builtin-log.c\n> @@ -217,6 +217,7 @@ static int git_format_config(const char *var,\n> const char *value)\n> \n> static FILE *realstdout = NULL;\n> static const char *output_directory = NULL;\n> +static int psuffix = 0;\n\nWhy not\n\n\tstatic const char *file_extension = \".txt\"\n\nHmm?\n\n> \t}\n> -\tstrcpy(filename + len, \".txt\");\n\nHere, you would write\n\n\tstrcpy(filename + len, file_extension);\n\n> @@ -436,6 +441,8 @@ int cmd_format_patch(int argc, const char **argv,\n> const char *prefix)\n> \t\t\t\tdie(\"Need a Message-Id for --in-reply-to\");\n> \t\t\tin_reply_to = argv[i];\n> \t\t}\n> +\t\telse if (!strcmp(argv[i], \"--psuffix\"))\n> +\t\t\tpsuffix = 1;\n\nand here:\n\n\t\telse if (!strncmp(argv[i], \"--extension=\", 12))\n\t\t\tfile_extension = argv[i] + 12;\n\nYou'd call it with \"--extension=.patch\", and if you really want, you can \nmake a config variable from it.\n\nCiao,\nDscho\n"},{"id":"31888","messageId":"625fc13d0701170650j5a9eb7dbyc7527d9c2b999076@mail.gmail.com","threadId":"6410","inReplyTo":"Pine.LNX.4.63.0701171446410.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"Josh Boyer","fromEmail":"jwboyer@gmail.com","sentAt":"2007-01-17T14:50:36Z","receivedAt":"2007-01-17T14:50:36Z","isPatch":false,"sender":{"key":"jwboyer@gmail.com","avatar":null},"body":"On 1/17/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Wed, 17 Jan 2007, Josh Boyer wrote:\n>\n> > Could we add an option to git-format-patch to use \".patch\" as the file\n> > suffix instead of \".txt\"? Something like the below?\n> >\n> > diff --git a/builtin-log.c b/builtin-log.c\n> > index a59b4ac..4eb2d32 100644\n> > --- a/builtin-log.c\n> > +++ b/builtin-log.c\n> > @@ -217,6 +217,7 @@ static int git_format_config(const char *var,\n> > const char *value)\n> >\n> > static FILE *realstdout = NULL;\n> > static const char *output_directory = NULL;\n> > +static int psuffix = 0;\n>\n> Why not\n>\n> static const char *file_extension = \".txt\"\n>\n> Hmm?\n\nYes, that's better. I was more going for \"would something like this\noption be accepted\" to start with. And I'm lazy, so the patch I wrote\nwas just an example for my specific use case :).\n\n> You'd call it with \"--extension=.patch\", and if you really want, you can\n> make a config variable from it.\n\nGood idea. I'll try and get this done soon-ish. I'm not very\nfamiliar with the git code, so if someone beats me to it, I won't be\ndisappointed in the least ;)\n\njosh\n"},{"id":"31893","messageId":"87ps9d7j6t.fsf@morpheus.local","threadId":"6410","inReplyTo":"625fc13d0701170510x8883539g93f43d9ddffe56f0@mail.gmail.com","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-01-17T15:43:22Z","receivedAt":"2007-01-17T15:43:22Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"\"Josh Boyer\" writes:\n\n> Hi All,\n>\n> I use git quite a bit to track my changes and then use\n> git-format-patch to generate patches to send on to others. For the\n> most part, it works great but I find myself constantly doing:\n>\n> mv xxxx-foo.txt xxxx-foo.patch\n\nSeconded. I would even prefer .patch to be default, but I guess a\nconfig parameter would help me there.\n\n-- \nDavid Kågedal\n"},{"id":"31895","messageId":"200701171639.l0HGdNq4021842@laptop13.inf.utfsm.cl","threadId":"6410","inReplyTo":"Pine.LNX.4.63.0701171446410.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-17T16:39:23Z","receivedAt":"2007-01-17T16:39:23Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Johannes Schindelin wrote:\n> On Wed, 17 Jan 2007, Josh Boyer wrote:\n> \n> > Could we add an option to git-format-patch to use \".patch\" as the file\n> > suffix instead of \".txt\"? Something like the below?\n> > \n> > diff --git a/builtin-log.c b/builtin-log.c\n> > index a59b4ac..4eb2d32 100644\n> > --- a/builtin-log.c\n> > +++ b/builtin-log.c\n> > @@ -217,6 +217,7 @@ static int git_format_config(const char *var,\n> > const char *value)\n> > \n> > static FILE *realstdout = NULL;\n> > static const char *output_directory = NULL;\n> > +static int psuffix = 0;\n> \n> Why not\n> \n> \tstatic const char *file_extension = \".txt\"\n\nNeed to keep the length of that around for allocating string space and\nsuch. Is the flexibility worth the hassle?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"31897","messageId":"45AE5585.2040406@op5.se","threadId":"6410","inReplyTo":"87ps9d7j6t.fsf@morpheus.local","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-17T16:57:41Z","receivedAt":"2007-01-17T16:57:41Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"David Kågedal wrote:\n> \"Josh Boyer\" writes:\n> \n>> Hi All,\n>>\n>> I use git quite a bit to track my changes and then use\n>> git-format-patch to generate patches to send on to others. For the\n>> most part, it works great but I find myself constantly doing:\n>>\n>> mv xxxx-foo.txt xxxx-foo.patch\n> \n> Seconded. I would even prefer .patch to be default, but I guess a\n> config parameter would help me there.\n> \n\nThirded, although I'd rather have it .gpatch, as it's a full commit with \nmessage and all. It isn't necessarily usable with the 'patch' program \nwithout manual massage first.\n\nI can live with .txt though. Not many other files I keep around have \nnames quite like \n0001-loadbalance_module-support-config-fanout-in-static-mesh.txt, so \nit's not as if I frequently confuse them.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"31898","messageId":"Pine.LNX.4.63.0701171805030.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"45AE5585.2040406@op5.se","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-17T17:05:59Z","receivedAt":"2007-01-17T17:05:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Jan 2007, Andreas Ericsson wrote:\n\n> It [a git patch] isn't necessarily usable with the 'patch' program \n> without manual massage first.\n\nAll \"patch\" programs I know are happy without any massage.\n\nCiao,\nDscho\n"},{"id":"31900","messageId":"7vejptsglj.fsf@assigned-by-dhcp.cox.net","threadId":"6410","inReplyTo":"87ps9d7j6t.fsf@morpheus.local","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-17T17:33:44Z","receivedAt":"2007-01-17T17:33:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kågedal writes:\n\n> \"Josh Boyer\" writes:\n>\n>> I use git quite a bit to track my changes and then use\n>> git-format-patch to generate patches to send on to others. For the\n>> most part, it works great but I find myself constantly doing:\n>>\n>> mv xxxx-foo.txt xxxx-foo.patch\n>\n> Seconded. I would even prefer .patch to be default, but I guess a\n> config parameter would help me there.\n\nTwo minor objections to changing the default are: (1) it's a\nchange and any change is bad ;-) and (2) the reason I changed it\nto .txt before submitting the original format-patch to Linus was\nbecause Emacs wanted to go into its \"diff\" mode when files are\nnamed with .patch suffix, which had two annoyances (read-only by\ndefault, and editing patch tried to automatically recount diff\nand its recounting screwed up in some cases I do not remember\nthe details about).\n\nI do not have a problem with a config or an option, though.\n"},{"id":"31906","messageId":"87lkk17c5v.fsf@morpheus.local","threadId":"6410","inReplyTo":"7vejptsglj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-01-17T18:15:08Z","receivedAt":"2007-01-17T18:15:08Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Junio C Hamano writes:\n\n> Emacs wanted to go into its \"diff\" mode when files are named with\n> .patch suffix, \n\nThis is probably the primary reason why I *want* it to be .patch. The\ndiff-mode in Emacs is really useful, and read-write mode is only a C-x\nC-q away.\n\n> which had two annoyances (read-only by default, and\n> editing patch tried to automatically recount diff and its recounting\n> screwed up in some cases I do not remember the details about).\n\nI rarely edit patches, but it has worked for me.\n\n-- \nDavid Kågedal\n"},{"id":"31907","messageId":"7v4pqpsbre.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6410","inReplyTo":"Pine.LNX.4.63.0701171446410.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"[PATCH] Introduce 'git-format-patch --suffix=patch'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-17T19:18:13Z","receivedAt":"2007-01-17T19:18:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The default can also be changed with \"format.suffix\" configuration.\n\nSigned-off-by: Junio C Hamano \n---\n\n Johannes Schindelin writes:\n\n > Why not\n >\n > \tstatic const char *file_extension = \".txt\"\n >\n > Hmm?\n\n Let's do this instead. By the way, there is a bug in the\n configuration parsing for format.headers from commit 20ff0680,\n which needs to be check NULLness of the value the same way as\n this one deals with format.suffix, which I've already fixed in\n my tree.\n\n Documentation/git-format-patch.txt | 13 ++++++++++++-\n builtin-log.c | 19 ++++++++++++++++---\n 2 files changed, 28 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex 67425dc..34abd2f 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n [verse]\n 'git-format-patch' [-n | -k] [-o | --stdout] [--attach] [--thread]\n \t [-s | --signoff] [--diff-options] [--start-number ]\n-\t\t [--in-reply-to=Message-Id]\n+\t\t [--in-reply-to=Message-Id] [--suffix=]\n \t\t [..]\n \n DESCRIPTION\n@@ -78,6 +78,12 @@ OPTIONS\n \treply to the given Message-Id, which avoids breaking threads to\n \tprovide a new patch series.\n \n+--suffix=::\n+\tInstead of using `txt` as the suffix for generated\n+\tfilenames, use specifed suffix. A common alternative is\n+\t`--suffix=patch`.\n+\n+\n CONFIGURATION\n -------------\n You can specify extra mail header lines to be added to each\n@@ -86,6 +92,11 @@ message in the repository configuration as follows:\n [format]\n headers = \"Organization: git-foo\\n\"\n \n+You can specify default suffix used:\n+\n+[format]\n+ suffix = patch\n+\n \n EXAMPLES\n --------\ndiff --git a/builtin-log.c b/builtin-log.c\nindex a59b4ac..04e3144 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -197,6 +197,7 @@ static int istitlechar(char c)\n \n static char *extra_headers = NULL;\n static int extra_headers_size = 0;\n+static const char *fmt_patch_suffix = \"txt\";\n \n static int git_format_config(const char *var, const char *value)\n {\n@@ -208,6 +209,12 @@ static int git_format_config(const char *var, const char *value)\n \t\tstrcat(extra_headers, value);\n \t\treturn 0;\n \t}\n+\tif (!strcmp(var, \"format.suffix\")) {\n+\t\tif (!value)\n+\t\t\tdie(\"format.suffix without value\");\n+\t\tfmt_patch_suffix = xstrdup(value);\n+\t\treturn 0;\n+\t}\n \tif (!strcmp(var, \"diff.color\") || !strcmp(var, \"color.diff\")) {\n \t\treturn 0;\n \t}\n@@ -223,9 +230,10 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject)\n \tchar filename[1024];\n \tchar *sol;\n \tint len = 0;\n+\tint suffix_len = strlen(fmt_patch_suffix) + 10; /* ., NUL and slop */\n \n \tif (output_directory) {\n-\t\tstrlcpy(filename, output_directory, 1010);\n+\t\tstrlcpy(filename, output_directory, 1000);\n \t\tlen = strlen(filename);\n \t\tif (filename[len - 1] != '/')\n \t\t\tfilename[len++] = '/';\n@@ -249,7 +257,10 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject)\n \t\t\t}\n \t\t}\n \n-\t\tfor (j = 0; len < 1024 - 6 && sol[j] && sol[j] != '\\n'; j++) {\n+\t\tfor (j = 0;\n+\t\t len < sizeof(filename) - suffix_len &&\n+\t\t\t sol[j] && sol[j] != '\\n';\n+\t\t j++) {\n \t\t\tif (istitlechar(sol[j])) {\n \t\t\t\tif (space) {\n \t\t\t\t\tfilename[len++] = '-';\n@@ -265,7 +276,7 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject)\n \t\twhile (filename[len - 1] == '.' || filename[len - 1] == '-')\n \t\t\tlen--;\n \t}\n-\tstrcpy(filename + len, \".txt\");\n+\tsprintf(filename + len, \".%s\", fmt_patch_suffix);\n \tfprintf(realstdout, \"%s\\n\", filename);\n \tfreopen(filename, \"w\", stdout);\n }\n@@ -436,6 +447,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \t\t\t\tdie(\"Need a Message-Id for --in-reply-to\");\n \t\t\tin_reply_to = argv[i];\n \t\t}\n+\t\telse if (!strncmp(argv[i], \"--suffix=\", 9))\n+\t\t\tfmt_patch_suffix = argv[i] + 9;\n \t\telse\n \t\t\targv[j++] = argv[i];\n \t}\n-- \n1.5.0.rc1.g5e1a2-dirty\n"},{"id":"31908","messageId":"45AE7710.40503@shadowen.org","threadId":"6410","inReplyTo":"7v4pqpsbre.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce 'git-format-patch --suffix=patch'","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2007-01-17T19:20:48Z","receivedAt":"2007-01-17T19:20:48Z","isPatch":true,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> The default can also be changed with \"format.suffix\" configuration.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> \n> Johannes Schindelin writes:\n> \n> > Why not\n> >\n> > \tstatic const char *file_extension = \".txt\"\n> >\n> > Hmm?\n> \n> Let's do this instead. By the way, there is a bug in the\n> configuration parsing for format.headers from commit 20ff0680,\n> which needs to be check NULLness of the value the same way as\n> this one deals with format.suffix, which I've already fixed in\n> my tree.\n> \n> Documentation/git-format-patch.txt | 13 ++++++++++++-\n> builtin-log.c | 19 ++++++++++++++++---\n> 2 files changed, 28 insertions(+), 4 deletions(-)\n> \n> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\n> index 67425dc..34abd2f 100644\n> --- a/Documentation/git-format-patch.txt\n> +++ b/Documentation/git-format-patch.txt\n> @@ -11,7 +11,7 @@ SYNOPSIS\n> [verse]\n> 'git-format-patch' [-n | -k] [-o | --stdout] [--attach] [--thread]\n> \t [-s | --signoff] [--diff-options] [--start-number ]\n> -\t\t [--in-reply-to=Message-Id]\n> +\t\t [--in-reply-to=Message-Id] [--suffix=]\n> \t\t [..]\n> \n> DESCRIPTION\n> @@ -78,6 +78,12 @@ OPTIONS\n> \treply to the given Message-Id, which avoids breaking threads to\n> \tprovide a new patch series.\n> \n> +--suffix=::\n> +\tInstead of using `txt` as the suffix for generated\n> +\tfilenames, use specifed suffix. A common alternative is\n> +\t`--suffix=patch`.\n> +\n> +\n> CONFIGURATION\n> -------------\n> You can specify extra mail header lines to be added to each\n> @@ -86,6 +92,11 @@ message in the repository configuration as follows:\n> [format]\n> headers = \"Organization: git-foo\\n\"\n> \n> +You can specify default suffix used:\n> +\n> +[format]\n> + suffix = patch\n> +\n> \n> EXAMPLES\n> --------\n> diff --git a/builtin-log.c b/builtin-log.c\n> index a59b4ac..04e3144 100644\n> --- a/builtin-log.c\n> +++ b/builtin-log.c\n> @@ -197,6 +197,7 @@ static int istitlechar(char c)\n> \n> static char *extra_headers = NULL;\n> static int extra_headers_size = 0;\n> +static const char *fmt_patch_suffix = \"txt\";\n> \n> static int git_format_config(const char *var, const char *value)\n> {\n> @@ -208,6 +209,12 @@ static int git_format_config(const char *var, const char *value)\n> \t\tstrcat(extra_headers, value);\n> \t\treturn 0;\n> \t}\n> +\tif (!strcmp(var, \"format.suffix\")) {\n> +\t\tif (!value)\n> +\t\t\tdie(\"format.suffix without value\");\n> +\t\tfmt_patch_suffix = xstrdup(value);\n> +\t\treturn 0;\n> +\t}\n> \tif (!strcmp(var, \"diff.color\") || !strcmp(var, \"color.diff\")) {\n> \t\treturn 0;\n> \t}\n> @@ -223,9 +230,10 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject)\n> \tchar filename[1024];\n> \tchar *sol;\n> \tint len = 0;\n> +\tint suffix_len = strlen(fmt_patch_suffix) + 10; /* ., NUL and slop */\n> \n> \tif (output_directory) {\n> -\t\tstrlcpy(filename, output_directory, 1010);\n> +\t\tstrlcpy(filename, output_directory, 1000);\n> \t\tlen = strlen(filename);\n> \t\tif (filename[len - 1] != '/')\n> \t\t\tfilename[len++] = '/';\n> @@ -249,7 +257,10 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject)\n> \t\t\t}\n> \t\t}\n> \n> -\t\tfor (j = 0; len < 1024 - 6 && sol[j] && sol[j] != '\\n'; j++) {\n> +\t\tfor (j = 0;\n> +\t\t len < sizeof(filename) - suffix_len &&\n> +\t\t\t sol[j] && sol[j] != '\\n';\n> +\t\t j++) {\n> \t\t\tif (istitlechar(sol[j])) {\n> \t\t\t\tif (space) {\n> \t\t\t\t\tfilename[len++] = '-';\n> @@ -265,7 +276,7 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject)\n> \t\twhile (filename[len - 1] == '.' || filename[len - 1] == '-')\n> \t\t\tlen--;\n> \t}\n> -\tstrcpy(filename + len, \".txt\");\n> +\tsprintf(filename + len, \".%s\", fmt_patch_suffix);\n\nThis doesn't give us any possibility of not having a suffix. Can we not\ninclude the . in the suffix here so that we can specify it as \"\".\n\n> \tfprintf(realstdout, \"%s\\n\", filename);\n> \tfreopen(filename, \"w\", stdout);\n> }\n> @@ -436,6 +447,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n> \t\t\t\tdie(\"Need a Message-Id for --in-reply-to\");\n> \t\t\tin_reply_to = argv[i];\n> \t\t}\n> +\t\telse if (!strncmp(argv[i], \"--suffix=\", 9))\n> +\t\t\tfmt_patch_suffix = argv[i] + 9;\n> \t\telse\n> \t\t\targv[j++] = argv[i];\n> \t}\n\n-apw\n"},{"id":"31911","messageId":"7vzm8hqws4.fsf@assigned-by-dhcp.cox.net","threadId":"6410","inReplyTo":"45AE7710.40503@shadowen.org","subject":"Re: [PATCH] Introduce 'git-format-patch --suffix=patch'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-17T19:27:07Z","receivedAt":"2007-01-17T19:27:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Whitcroft writes:\n\n>> -\tstrcpy(filename + len, \".txt\");\n>> +\tsprintf(filename + len, \".%s\", fmt_patch_suffix);\n>\n> This doesn't give us any possibility of not having a suffix. Can we not\n> include the . in the suffix here so that we can specify it as \"\".\n\nI've considered it, but I do not think it is worth it. \n\nIf we did so, the configuration would look like:\n\n\t[format]\n\t\tsuffix = .txt\n\nwhich has a certain \"Huh?\" factor, and more importantly, a\ncareless user would end up with a patchfile that is named:\n\n\t0001-Introduce-git-format-patch-suffix-patchtxt\n\nwhich is I think much worse than not being able to say:\n\n\t0001-Introduce-git-format-patch-suffix-patch\n\nBut I do not care that much either way.\n"},{"id":"31914","messageId":"D085A8A2-F1EC-47EC-8D96-B8A06E483BDB@silverinsanity.com","threadId":"6410","inReplyTo":"7vzm8hqws4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce 'git-format-patch --suffix=patch'","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-17T19:51:57Z","receivedAt":"2007-01-17T19:51:57Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jan 17, 2007, at 2:27 PM, Junio C Hamano wrote:\n\n> Andy Whitcroft writes:\n>\n>>> -\tstrcpy(filename + len, \".txt\");\n>>> +\tsprintf(filename + len, \".%s\", fmt_patch_suffix);\n>>\n>> This doesn't give us any possibility of not having a suffix. Can \n>> we not\n>> include the . in the suffix here so that we can specify it as \"\".\n>\n> I've considered it, but I do not think it is worth it.\n\nI think that the best form of DWIM is that if the suffix is \"\", then \nyou simply skip the entire sprintf. Then any suffix has to have the \n'.', but no suffix doesn't have it. Additional DWIMMmery could \nremove an initial '.' from the suffix so that users expecting it to \nbe there don't get \"..\" in their file.\n\nPatch (on top of yours) should follow shortly.\n\n~~ Brian\n"},{"id":"31915","messageId":"7vps9dqvdq.fsf@assigned-by-dhcp.cox.net","threadId":"6410","inReplyTo":"D085A8A2-F1EC-47EC-8D96-B8A06E483BDB@silverinsanity.com","subject":"Re: [PATCH] Introduce 'git-format-patch --suffix=patch'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-17T19:57:21Z","receivedAt":"2007-01-17T19:57:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gernhardt writes:\n\n> I think that the best form of DWIM is that if the suffix is \"\", then\n> you simply skip the entire sprintf. Then any suffix has to have the\n> '.', but no suffix doesn't have it. Additional DWIMMmery could\n> remove an initial '.' from the suffix so that users expecting it to\n> be there don't get \"..\" in their file.\n\nI think it is generally accepted on this list that that kind of\nDWIMmery is bad.\n"},{"id":"31917","messageId":"6B51EBBF-1499-4E9B-856C-39DA5B8C4CC7@silverinsanity.com","threadId":"6410","inReplyTo":"7vps9dqvdq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce 'git-format-patch --suffix=patch'","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-17T20:08:24Z","receivedAt":"2007-01-17T20:08:24Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jan 17, 2007, at 2:57 PM, Junio C Hamano wrote:\n\n> Brian Gernhardt writes:\n>\n>> I think that the best form of DWIM is that if the suffix is \"\", then\n>> you simply skip the entire sprintf. Then any suffix has to have the\n>> '.', but no suffix doesn't have it. Additional DWIMMmery could\n>> remove an initial '.' from the suffix so that users expecting it to\n>> be there don't get \"..\" in their file.\n>\n> I think it is generally accepted on this list that that kind of\n> DWIMmery is bad.\n\nThe first part seems like the easiest way to allow --suffix=\"\" \nactually remove the suffix while removing the \"Huh?\" factor you \nmentioned. In fact, having --suffix=\"\" add a suffix of \".\" is \nsomewhat confusing all on it's own.\n\nThe second just seems like an easy way to keep stupid mistakes from \noccurring, but isn't needed.\n\nI'll still post the patch, but not add the extra DWIMmery. I think \nit's a better alternative than having to choose between putting \".\" \nin all the suffixes and always having \".\" on the file.\n\n~~ Brian\n"},{"id":"31919","messageId":"625fc13d0701171218i31585558wf89374eae9485341@mail.gmail.com","threadId":"6410","inReplyTo":"7vejptsglj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"Josh Boyer","fromEmail":"jwboyer@gmail.com","sentAt":"2007-01-17T20:18:57Z","receivedAt":"2007-01-17T20:18:57Z","isPatch":false,"sender":{"key":"jwboyer@gmail.com","avatar":null},"body":"On 1/17/07, Junio C Hamano wrote:\n> David Kågedal writes:\n>\n> > \"Josh Boyer\" writes:\n> >\n> >> I use git quite a bit to track my changes and then use\n> >> git-format-patch to generate patches to send on to others. For the\n> >> most part, it works great but I find myself constantly doing:\n> >>\n> >> mv xxxx-foo.txt xxxx-foo.patch\n> >\n> > Seconded. I would even prefer .patch to be default, but I guess a\n> > config parameter would help me there.\n>\n> Two minor objections to changing the default are: (1) it's a\n> change and any change is bad ;-) and (2) the reason I changed it\n> to .txt before submitting the original format-patch to Linus was\n> because Emacs wanted to go into its \"diff\" mode when files are\n> named with .patch suffix, which had two annoyances (read-only by\n> default, and editing patch tried to automatically recount diff\n> and its recounting screwed up in some cases I do not remember\n> the details about).\n\nWell there's your problem. You're using Emacs. ;)\n\nSeriously though, I'll try and fix up the patch a bit soon and resubmit.\n\njosh\n"},{"id":"31920","messageId":"625fc13d0701171220l25c42cbbwb22b4bf32edc0514@mail.gmail.com","threadId":"6410","inReplyTo":"625fc13d0701171218i31585558wf89374eae9485341@mail.gmail.com","subject":"Re: [RFC] Add a suffix option to git-format-patch","fromName":"Josh Boyer","fromEmail":"jwboyer@gmail.com","sentAt":"2007-01-17T20:20:53Z","receivedAt":"2007-01-17T20:20:53Z","isPatch":false,"sender":{"key":"jwboyer@gmail.com","avatar":null},"body":"On 1/17/07, Josh Boyer wrote:\n>\n> Seriously though, I'll try and fix up the patch a bit soon and resubmit.\n\nI see Junio beat me to it. Excellent :)\n\njosh\n"},{"id":"31921","messageId":"20070117202221.GA14042@176.242.249.10.in-addr.arpa","threadId":"6410","inReplyTo":"7v4pqpsbre.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] Make format-patch --suffix=\"\" not add any suffix","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-17T20:22:21Z","receivedAt":"2007-01-17T20:22:21Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"Having a suffix of \".\" when the user explicitly asked for none is\nsomewhat confusing.\n\nSigned-off-by: Brian Gernhardt \n---\n builtin-log.c | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 04e3144..a60a987 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -276,7 +276,8 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject)\n \t\twhile (filename[len - 1] == '.' || filename[len - 1] == '-')\n \t\t\tlen--;\n \t}\n-\tsprintf(filename + len, \".%s\", fmt_patch_suffix);\n+\tif (fmt_patch_suffix[0] != '\\0')\n+\t\tsprintf(filename + len, \".%s\", fmt_patch_suffix);\n \tfprintf(realstdout, \"%s\\n\", filename);\n \tfreopen(filename, \"w\", stdout);\n }\n-- \n1.5.0.rc1.gfb138\n"},{"id":"31929","messageId":"7vd55dp5a3.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6410","inReplyTo":"7vsle9p8pg.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-18T00:06:28Z","receivedAt":"2007-01-18T00:06:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Editors often give easier handling of patch files if the\nfilename ends with .patch, so use it instead of .txt.\n\nSigned-off-by: Junio C Hamano \n---\n\n Junio C Hamano writes:\n\n > \"Josh Boyer\" writes:\n >\n >> On 1/17/07, Junio C Hamano wrote:\n >>\n >>> Two minor objections to changing the default are: (1) it's a\n >>> change and any change is bad ;-) and (2) the reason I changed it\n >>> to .txt before submitting the original format-patch to Linus was\n >>> because Emacs wanted to go into its \"diff\" mode when files are\n >>> named with .patch suffix, which had two annoyances (read-only by\n >>> default, and editing patch tried to automatically recount diff\n >>> and its recounting screwed up in some cases I do not remember\n >>> the details about).\n >>\n >> Well there's your problem. You're using Emacs. ;)\n >\n > Fair enough. Its probably that there is something wrong in the\n > way I am using Emacs diff/patch editing mode. Even if the\n > problem I had were because of bugs in Emacs, the users of git\n > should not have to suffer from \"unusual\" suffixes to work them\n > around.\n >\n > So that lifts one of the objections. What should be done to the\n > other one --- time for a quick poll?\n\n Documentation/git-format-patch.txt | 15 +++++++--------\n .../howto/rebase-from-internal-branch.txt | 2 +-\n builtin-log.c | 2 +-\n 3 files changed, 9 insertions(+), 10 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex c0ffe99..49f51bb 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -79,9 +79,9 @@ OPTIONS\n \tprovide a new patch series.\n \n --suffix=.::\n-\tInstead of using `.txt` as the suffix for generated\n+\tInstead of using `.patch` as the suffix for generated\n \tfilenames, use specifed suffix. A common alternative is\n-\t`--suffix=.patch`.\n+\t`--suffix=.txt`.\n +\n Note that you would need to include the leading dot `.` if you\n want a filename like `0001-description-of-my-change.patch`, and\n@@ -91,15 +91,14 @@ not add any suffix.\n CONFIGURATION\n -------------\n You can specify extra mail header lines to be added to each\n-message in the repository configuration as follows:\n+message in the repository configuration. Also you can specify\n+the default suffix different from the built-in one:\n \n+------------\n [format]\n headers = \"Organization: git-foo\\n\"\n-\n-You can specify default suffix used:\n-\n-[format]\n- suffix = .patch\n+ suffix = .txt\n+------------\n \n \n EXAMPLES\ndiff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt\nindex fcd64e9..3b3a5c2 100644\n--- a/Documentation/howto/rebase-from-internal-branch.txt\n+++ b/Documentation/howto/rebase-from-internal-branch.txt\n@@ -106,7 +106,7 @@ prepare #2 and #3 for e-mail submission.\n \n $ git format-patch master^^ master\n \n-This creates two files, 0001-XXXX.txt and 0002-XXXX.txt. Send\n+This creates two files, 0001-XXXX.patch and 0002-XXXX.patch. Send\n them out \"To: \" your project maintainer and \"Cc: \" your mailing\n list. You could use contributed script git-send-email if\n your host has necessary perl modules for this, but your usual\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 930cc04..f3cff13 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -197,7 +197,7 @@ static int istitlechar(char c)\n \n static char *extra_headers = NULL;\n static int extra_headers_size = 0;\n-static const char *fmt_patch_suffix = \".txt\";\n+static const char *fmt_patch_suffix = \".patch\";\n \n static int git_format_config(const char *var, const char *value)\n {\n-- \n1.5.0.rc1.gde38\n"},{"id":"31935","messageId":"Pine.LNX.4.63.0701180205360.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"7vd55dp5a3.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T01:06:11Z","receivedAt":"2007-01-18T01:06:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nsince this is a poll, count me as neutral. I don't care either way.\n\nCiao,\nDscho\n"},{"id":"31936","messageId":"Pine.LNX.4.63.0701180211280.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"7v4pqpsbre.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce 'git-format-patch --suffix=patch'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T01:11:47Z","receivedAt":"2007-01-18T01:11:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Acked-by: Johannes Schindelin \n"},{"id":"31946","messageId":"81b0412b0701172359y1ef4f936pcdcb2de53d6bd468@mail.gmail.com","threadId":"6410","inReplyTo":"7vd55dp5a3.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T07:59:21Z","receivedAt":"2007-01-18T07:59:21Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Junio C Hamano wrote:\n> Editors often give easier handling of patch files if the\n> filename ends with .patch, so use it instead of .txt.\n\nI'd like to see \".patch\" there, but...\n\nI have to mention, though, that the majority of the editing\nprograms is used on that stupid thing called windows\nand they usually and most notably have no idea what\nthe patch is and how could it happen a file extension\nhaving more than 3 characters. I am already having\nhard time explaining to my coworkers what the patch\n(the program and the file) is. With mixed success.\n\nAlso, how many mail clients know that .patch is actually\na text and not application/binary? It'll make patch\nreviewing harder for some (not sure if I'd like a review\nof such a person, though).\n"},{"id":"31947","messageId":"20070118080613.GE23124@spearce.org","threadId":"6410","inReplyTo":"81b0412b0701172359y1ef4f936pcdcb2de53d6bd468@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-18T08:06:13Z","receivedAt":"2007-01-18T08:06:13Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> Also, how many mail clients know that .patch is actually\n> a text and not application/binary? It'll make patch\n> reviewing harder for some (not sure if I'd like a review\n> of such a person, though).\n\nPatches intended for review should be sent inline, not attached.\nThus the file extension has no impact on how the mail client should\ntreat it.\n\nDon't count people out just because they cannot read a *.patch file\nAll constructive feedback is valuable, no matter its source. Of\ncourse I did qualify that with \"constructive\"... ;-)\n\n-- \nShawn.\n"},{"id":"31949","messageId":"81b0412b0701180018i208e4158k2dd3e9ecdfa79b13@mail.gmail.com","threadId":"6410","inReplyTo":"20070118080613.GE23124@spearce.org","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T08:18:47Z","receivedAt":"2007-01-18T08:18:47Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Shawn O. Pearce wrote:\n> Alex Riesen wrote:\n> > Also, how many mail clients know that .patch is actually\n> > a text and not application/binary? It'll make patch\n> > reviewing harder for some (not sure if I'd like a review\n> > of such a person, though).\n>\n> Patches intended for review should be sent inline, not attached.\n\nThere is again this word \"should\". Are you sure it has any _real_\nmeaning? For a person who knows about revision management\nfrom something like Perforce?\n\n> Thus the file extension has no impact on how the mail client should\n> treat it.\n\nHe will attach it. It's typical for outlook users. He will even put it\nin HTML-formatted mail, because that's the default format for\noutlook messages.\n\n> Don't count people out just because they cannot read a *.patch file\n\nI don't. I just know how hard is it to explain what source is and\nwhy it is better than a \"C++ file\".\n\n> All constructive feedback is valuable, no matter its source. Of\n> course I did qualify that with \"constructive\"... ;-)\n\nIt is. That's why I did try to explain it to some. That's how I know\nabout explaining. I'm very pessimistic now, sorry.\n"},{"id":"31950","messageId":"7v64b4ohcj.fsf@assigned-by-dhcp.cox.net","threadId":"6410","inReplyTo":"81b0412b0701172359y1ef4f936pcdcb2de53d6bd468@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-18T08:43:24Z","receivedAt":"2007-01-18T08:43:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> I'd like to see \".patch\" there, but...\n>\n> I have to mention, though, that the majority of the editing\n> programs is used on that stupid thing called windows ...\n\nEven if majority of git target audience were on Windows, I\nthought majority of Windows users are on either VFAT or NTFS and\nnot DOS 8.3 filesystems these days.\n\n> Also, how many mail clients know that .patch is actually\n> a text and not application/binary? It'll make patch\n> reviewing harder for some (not sure if I'd like a review\n> of such a person, though).\n\nIs it common for popular MUAs to have a single command that lets\nyou specify a file and depending on its suffix paste it inline\nor make it an attachment? I had an impression that most have\nseparate commands for \"read text from file (as opposed to\ntyping)\" and \"attach a file (of random type, not necessarily and\nmore often than not text)\".\n\nThe output of format-patch is not meant to be used as an\nattachment (it is \"read text from file\" kind), so I do not think\nyour worry applies here. Maybe something I am missing?\n"},{"id":"31952","messageId":"7vps9cn1ip.fsf@assigned-by-dhcp.cox.net","threadId":"6410","inReplyTo":"81b0412b0701180018i208e4158k2dd3e9ecdfa79b13@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-18T09:10:38Z","receivedAt":"2007-01-18T09:10:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> On 1/18/07, Shawn O. Pearce wrote:\n\n>> Thus the file extension has no impact on how the mail client should\n>> treat it.\n>\n> He will attach it. It's typical for outlook users.\n\nIf that is the case, I highly suspect that it is one more reason\nnot to mark the file with .txt; Outlook may say \"Hey, it's TEXT,\nso let's linewrap it, quote-balance it and add all sorts of nice\nfrills to make it easier to read for human consumption\". \n\nAssuming that it does not understand what a .patch is, we would\nhave a better chance to force it not to look at nor touch the\ncontents, and not getting our patches corrupted.\n"},{"id":"31953","messageId":"81b0412b0701180121i69661d36yba046222e654832b@mail.gmail.com","threadId":"6410","inReplyTo":"7vps9cn1ip.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T09:21:05Z","receivedAt":"2007-01-18T09:21:05Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Junio C Hamano wrote:\n> >> Thus the file extension has no impact on how the mail client should\n> >> treat it.\n> >\n> > He will attach it. It's typical for outlook users.\n>\n> If that is the case, I highly suspect that it is one more reason\n> not to mark the file with .txt; Outlook may say \"Hey, it's TEXT,\n> so let's linewrap it, quote-balance it and add all sorts of nice\n> frills to make it easier to read for human consumption\".\n\nNo, it wont (and doesn't). It would be \"too clever to be useful\".\nOutlook is too _stupid_ to be useful.\n"},{"id":"31954","messageId":"81b0412b0701180135r505a75a5j172c70792d6569c0@mail.gmail.com","threadId":"6410","inReplyTo":"7v64b4ohcj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T09:35:03Z","receivedAt":"2007-01-18T09:35:03Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Junio C Hamano wrote:\n>\n> > I'd like to see \".patch\" there, but...\n> >\n> > I have to mention, though, that the majority of the editing\n> > programs is used on that stupid thing called windows ...\n>\n> Even if majority of git target audience were on Windows, I\n> thought majority of Windows users are on either VFAT or NTFS and\n> not DOS 8.3 filesystems these days.\n\nThe filesystems are not 8.3, the programs are.\n\n> > Also, how many mail clients know that .patch is actually\n> > a text and not application/binary? It'll make patch\n> > reviewing harder for some (not sure if I'd like a review\n> > of such a person, though).\n>\n> Is it common for popular MUAs to have a single command that lets\n> you specify a file and depending on its suffix paste it inline\n> or make it an attachment? I had an impression that most have\n> separate commands for \"read text from file (as opposed to\n> typing)\" and \"attach a file (of random type, not necessarily and\n> more often than not text)\".\n\nNo, they don't :) They only have \"attach\" and drag-drop (which does the same).\n\n> The output of format-patch is not meant to be used as an\n> attachment (it is \"read text from file\" kind), so I do not think\n> your worry applies here. Maybe something I am missing?\n\nYes, the experience being a damned corporate windows user\nin a novell netware network with 50-year old admin fixated on\nmicrosoft exchange, not to mention Outlook Express users...\n\nI think we'd raising the entry barrier with choosing the defaults\nbeing so convenient for us. Well, the real-life programmers\nare less of Unix-liking kind. They are more lazy and demotivated\nkind, and Git will be _forced_ on them. It almost certainly\nwill not be their choice. Not always, some'll like it (heck, I know\npeople who swear by Perforce!), but most have a job, source\nof income, and not the profession (like in professional pride).\n\nAs much as like Unix and everything related, I think it is\nnot reasonable to try to change the majority. Not unless\nwe have something earth-shattering. Well, git is, but\n0001-fix....patch in email attachment probably not.\n"},{"id":"31955","messageId":"87y7o0mzcy.fsf@wine.dyndns.org","threadId":"6410","inReplyTo":"81b0412b0701172359y1ef4f936pcdcb2de53d6bd468@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2007-01-18T09:57:17Z","receivedAt":"2007-01-18T09:57:17Z","isPatch":true,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"\"Alex Riesen\" writes:\n\n> Also, how many mail clients know that .patch is actually\n> a text and not application/binary? It'll make patch\n> reviewing harder for some (not sure if I'd like a review\n> of such a person, though).\n\nOTOH such mail clients usually also think they can freely reformat\ntext files, leading to unusable patches. A .patch extension would\nhelp avoid that type of breakage, so I think it's a good idea.\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"31965","messageId":"625fc13d0701180352m151cceb3lf9c00b6cf0ae937b@mail.gmail.com","threadId":"6410","inReplyTo":"81b0412b0701180135r505a75a5j172c70792d6569c0@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Josh Boyer","fromEmail":"jwboyer@gmail.com","sentAt":"2007-01-18T11:52:38Z","receivedAt":"2007-01-18T11:52:38Z","isPatch":true,"sender":{"key":"jwboyer@gmail.com","avatar":null},"body":"On 1/18/07, Alex Riesen wrote:\n> I think we'd raising the entry barrier with choosing the defaults\n> being so convenient for us. Well, the real-life programmers\n> are less of Unix-liking kind. They are more lazy and demotivated\n> kind, and Git will be _forced_ on them. It almost certainly\n> will not be their choice. Not always, some'll like it (heck, I know\n> people who swear by Perforce!), but most have a job, source\n> of income, and not the profession (like in professional pride).\n\nreal-life programmers? Please don't generalize. It's insulting.\n\n> As much as like Unix and everything related, I think it is\n> not reasonable to try to change the majority. Not unless\n> we have something earth-shattering. Well, git is, but\n> 0001-fix....patch in email attachment probably not.\n\nI would venture to say that the _majority_ of git users are not using\nWindows. In this enviroment, Linux is likely the dominant OS,\nfollowed by other *nix. So changing the extention to benefit the\nmajorit of _git's_ users is a good thing.\n\njosh\n"},{"id":"31967","messageId":"45AF6AC6.2060206@op5.se","threadId":"6410","inReplyTo":"7v64b4ohcj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-18T12:40:38Z","receivedAt":"2007-01-18T12:40:38Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> Is it common for popular MUAs to have a single command that lets\n> you specify a file and depending on its suffix paste it inline\n> or make it an attachment? I had an impression that most have\n> separate commands for \"read text from file (as opposed to\n> typing)\" and \"attach a file (of random type, not necessarily and\n> more often than not text)\".\n> \n\nMost have only \"attach\" through various means of point-and-click and \ndrag-and-drop. Thunderbird too lacks the very basic ability of \"include \nthis file as part of the message\". I still haven't been able to find an \naddon for it that does just that.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"31968","messageId":"Pine.LNX.4.63.0701181433261.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"625fc13d0701180352m151cceb3lf9c00b6cf0ae937b@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T13:33:56Z","receivedAt":"2007-01-18T13:33:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Josh Boyer wrote:\n\n> real-life programmers? Please don't generalize. It's insulting.\n\nWhat? Programmers with a real life? Don't be silly ;-)\n\nCiao,\nDscho\n"},{"id":"31970","messageId":"81b0412b0701180540x15d20453s3dbc0c061fd06d50@mail.gmail.com","threadId":"6410","inReplyTo":"625fc13d0701180352m151cceb3lf9c00b6cf0ae937b@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T13:40:49Z","receivedAt":"2007-01-18T13:40:49Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Josh Boyer wrote:\n> > I think we'd raising the entry barrier with choosing the defaults\n> > being so convenient for us. Well, the real-life programmers\n> > are less of Unix-liking kind. They are more lazy and demotivated\n> > kind, and Git will be _forced_ on them. It almost certainly\n> > will not be their choice. Not always, some'll like it (heck, I know\n> > people who swear by Perforce!), but most have a job, source\n> > of income, and not the profession (like in professional pride).\n>\n> real-life programmers? Please don't generalize. It's insulting.\n\nJust because you are not able to realize that the count of\nwindows-based projects is still superior to that of say...\n\"likable\" systems, they wont magically disappear.\nIf that is the case, I think I do some more insulting\nand say that they are not only real-life but also will never\naccept the statement of their ways being wrong, however\nstupid they may appear. That's just how it is, count them if\nyou don't believe me.\n\n> > As much as like Unix and everything related, I think it is\n> > not reasonable to try to change the majority. Not unless\n> > we have something earth-shattering. Well, git is, but\n> > 0001-fix....patch in email attachment probably not.\n>\n> I would venture to say that the _majority_ of git users are not using\n> Windows.\n\nThe _real_ majority of the programmers desperately need a better\nVCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.\n\n> In this enviroment, Linux is likely the dominant OS,\n> followed by other *nix. So changing the extention to benefit the\n> majorit of _git's_ users is a good thing.\n\nYes. For me and you. One of my coworkers knows nothing about patches,\nbut wants (and perfectly able to) review my code. He has usable brains\nand is able to figure out what \"+\" and \"-\" is (he has, by now). He hasn't\neven realized that it was an automatically generated information, as\nI sent a patch to him first time, thought it was just a funny way to\ndocument changes (and was surprised when I told him a patch can be\napplied automatically, even if the original file is not exactly the same).\nBut he is a typical windows-trained programmer. Lazy, unmotivated and\nhappily married. He does programming by accident (was smart enough\nto learn the basics of the trade). Why would he want to take the an\nextra step of figuring out what that strange \"0001-...patch\" means?\nNow, I know him, would never think about sending him a real patch.\nI'm kinda grown and tired, and need the bastard, too. Someone younger\nwill just call him idiot and \"improve\" the situation by telling him about\n\"stupid windows\" and \"he should the right ways\". Just to be answered\n\"it worked for some millions programmers before you\" and \"I told your\nmanager you making problems and are hard to communicate with\".\n\nPeople often understand \"funny ways\" the others may have. They\ndon't like been told they are wrong or stupid (especially when they\nactually are stupid).\n"},{"id":"31971","messageId":"81b0412b0701180546ge46e6fcm17421b0e5b45b6ba@mail.gmail.com","threadId":"6410","inReplyTo":"Pine.LNX.4.63.0701181433261.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T13:46:32Z","receivedAt":"2007-01-18T13:46:32Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Johannes Schindelin wrote:\n>\n> > real-life programmers? Please don't generalize. It's insulting.\n>\n> What? Programmers with a real life? Don't be silly ;-)\n>\n\nI know a married drinking black-belt doing Delphi.\nHe say he has \"programmer\" written all over him.\nWe saw to it once, even :)\n"},{"id":"31974","messageId":"45AF7FE8.5060003@op5.se","threadId":"6410","inReplyTo":"81b0412b0701180540x15d20453s3dbc0c061fd06d50@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-18T14:10:48Z","receivedAt":"2007-01-18T14:10:48Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n> On 1/18/07, Josh Boyer wrote:\n>> > As much as like Unix and everything related, I think it is\n>> > not reasonable to try to change the majority. Not unless\n>> > we have something earth-shattering. Well, git is, but\n>> > 0001-fix....patch in email attachment probably not.\n>>\n>> I would venture to say that the _majority_ of git users are not using\n>> Windows.\n> \n> The _real_ majority of the programmers desperately need a better\n> VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.\n> \n\nThey're free to use git ofcourse, provided they install cygwin or help \nmigrate it to run natively on windows. I don't think anyone would cry if \na competent cross-platform programmer stepped up and started submitting \npatches to get git working on windows without having to resort to the \ncygwin emulation layer.\n\nThe thing is, no-one's getting paid for it, so until someone *does* step \nup, it won't happen, as 95% of the *current* git users are still running \nwhat we on this list will indefinitely refer to as \"a sane OS\".\n\n>> In this enviroment, Linux is likely the dominant OS,\n>> followed by other *nix. So changing the extention to benefit the\n>> majorit of _git's_ users is a good thing.\n> \n> Yes. For me and you. One of my coworkers knows nothing about patches,\n> but wants (and perfectly able to) review my code. He has usable brains\n> and is able to figure out what \"+\" and \"-\" is (he has, by now). He hasn't\n> even realized that it was an automatically generated information, as\n> I sent a patch to him first time, thought it was just a funny way to\n> document changes (and was surprised when I told him a patch can be\n> applied automatically, even if the original file is not exactly the same).\n> But he is a typical windows-trained programmer. Lazy, unmotivated and\n> happily married. He does programming by accident (was smart enough\n> to learn the basics of the trade). Why would he want to take the an\n> extra step of figuring out what that strange \"0001-...patch\" means?\n> Now, I know him, would never think about sending him a real patch.\n> I'm kinda grown and tired, and need the bastard, too. Someone younger\n> will just call him idiot and \"improve\" the situation by telling him about\n> \"stupid windows\" and \"he should the right ways\". Just to be answered\n> \"it worked for some millions programmers before you\" and \"I told your\n> manager you making problems and are hard to communicate with\".\n> \n> People often understand \"funny ways\" the others may have. They\n> don't like been told they are wrong or stupid (especially when they\n> actually are stupid).\n\n\nI still don't see the problem. When he understands (and uses) git, the \nname and look of the patch will become blindingly clear to him, and then \nit doesn't matter if it's called .txt or .patch. He might even have some \ntool by then that displays patches color-coded and what-not (there are a \nplethora of such tools for Windows already, most of which register \n.patch and .diff as file-types they handle).\n\nOtoh, *until* he uses git, the change doesn't affect him, so why bother \ncatering for his needs?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"31976","messageId":"Pine.LNX.4.63.0701181513220.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"45AF7FE8.5060003@op5.se","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T14:15:58Z","receivedAt":"2007-01-18T14:15:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Andreas Ericsson wrote:\n\n> I still don't see the problem. When he understands (and uses) git, the \n> name and look of the patch will become blindingly clear to him,\n\nNot so. Never underestimate mental inertia.\n\nRecently, a co-worker (in a database-backed webapplication project!) asked \nwhat an SQL injection might be.\n\nOf 5 developers, only 2 were able to answer!\n\nFace it, there are a lot of incompetent programmers out there. And I am \nvery happy you put up with me on this list.\n\nCiao,\nDscho\n"},{"id":"31978","messageId":"81b0412b0701180641v55987657t331d6a1868dabee0@mail.gmail.com","threadId":"6410","inReplyTo":"45AF7FE8.5060003@op5.se","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T14:41:39Z","receivedAt":"2007-01-18T14:41:39Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Andreas Ericsson wrote:\n> Alex Riesen wrote:\n> > On 1/18/07, Josh Boyer wrote:\n> >> > As much as like Unix and everything related, I think it is\n> >> > not reasonable to try to change the majority. Not unless\n> >> > we have something earth-shattering. Well, git is, but\n> >> > 0001-fix....patch in email attachment probably not.\n> >>\n> >> I would venture to say that the _majority_ of git users are not using\n> >> Windows.\n> >\n> > The _real_ majority of the programmers desperately need a better\n> > VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.\n>\n> They're free to use git ofcourse, provided they install cygwin or help\n> migrate it to run natively on windows. I don't think anyone would cry if\n\nMy example had cygwin installed for him. Is it too unusual?\n\n> a competent cross-platform programmer stepped up and started submitting\n> patches to get git working on windows without having to resort to the\n> cygwin emulation layer.\n\ndon't think so. I _would_ cry seeing how fork(2) gets ported to Windows,\nand you will, probably... after seeing how it is done in cygwin.\n\n> The thing is, no-one's getting paid for it, so until someone *does* step\n> up, it won't happen, as 95% of the *current* git users are still running\n> what we on this list will indefinitely refer to as \"a sane OS\".\n\n95% of the current users probably is not even 1% of all programmers\nwho would gladly use it and maybe less than a fraction of percent of\nthe ones who need it.\n\n> > People often understand \"funny ways\" the others may have. They\n> > don't like been told they are wrong or stupid (especially when they\n> > actually are stupid).\n>\n> I still don't see the problem. When he understands (and uses) git, the\n\nhe does not use git. He knows what the patch is (now I have explained\nit to him), I suppose he would still be mildly surprised seeing a file.patch,\nbut he'll probably recover.\n\n> name and look of the patch will become blindingly clear to him, and then\n> it doesn't matter if it's called .txt or .patch. He might even have some\n> tool by then that displays patches color-coded and what-not (there are a\n> plethora of such tools for Windows already, most of which register\n> .patch and .diff as file-types they handle).\n\nThat wont happen until windows registers it for them. And that, again,\nwont ever happen. Every user will register .patch to notepad, visual\nstudio or ultraedit or something else for himself.\n\n> Otoh, *until* he uses git, the change doesn't affect him,\n\nactually, patch works for git patches, so format-patch produces\nfiles useful output for anyone.\n\nBTW, Junio, how about making the _default_ settable at compile time?\nIt'd be reasonable to allow local installations choose to default to what\nthey find the most paranoid?\n\n> so why bother catering for his needs?\n\nI don't know. It's kind of good style lately.\n"},{"id":"31979","messageId":"Pine.LNX.4.63.0701181547440.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"81b0412b0701180641v55987657t331d6a1868dabee0@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T14:49:28Z","receivedAt":"2007-01-18T14:49:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Alex Riesen wrote:\n\n> [discussion about suffix being \"patch\" or \"txt\" per default]\n>\n> BTW, Junio, how about making the _default_ settable at compile time?\n> It'd be reasonable to allow local installations choose to default to what\n> they find the most paranoid?\n\nBetter control that with templates.\n\nCiao,\nDscho\n"},{"id":"31981","messageId":"81b0412b0701180653i7cc0c87md7a9c94a10fa3b24@mail.gmail.com","threadId":"6410","inReplyTo":"Pine.LNX.4.63.0701181547440.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T14:53:29Z","receivedAt":"2007-01-18T14:53:29Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Johannes Schindelin wrote:\n> > BTW, Junio, how about making the _default_ settable at compile time?\n> > It'd be reasonable to allow local installations choose to default to what\n> > they find the most paranoid?\n>\n> Better control that with templates.\n>\n\nDo we have a template for config already? I thought they were only for hooks...\n"},{"id":"31993","messageId":"45AF8DCA.9030008@etek.chalmers.se","threadId":"6410","inReplyTo":"45AF6AC6.2060206@op5.se","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Lukas Sandström","fromEmail":"lukass@etek.chalmers.se","sentAt":"2007-01-18T15:10:02Z","receivedAt":"2007-01-18T15:10:02Z","isPatch":true,"sender":{"key":"luksan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152281?v=4"},"body":"Andreas Ericsson wrote:\n> Most have only \"attach\" through various means of point-and-click and\n> drag-and-drop. Thunderbird too lacks the very basic ability of \"include\n> this file as part of the message\". I still haven't been able to find an\n> addon for it that does just that.\n\nI use the External Editor extension with Thunderbird (it's mentioned in SubmittingPatches).\n\nThe script below is used as the external editor, which gives me an easy way to send patches\ninline with Thunderbird.\n\n/Lukas\n\n#!/bin/bash\n\nCONFFILE=~/.appprc\n\nif [ -e \"$CONFFILE\" ] ; then\n\tLAST_DIR=`grep \"^LAST_DIR=\" $CONFFILE|sed -e 's/^LAST_DIR=//'`\n\tcd $LAST_DIR\nelse\n\tcd > /dev/null\nfi\n\nPATCH=$(zenity --file-selection)\n\nif [ \"$?\" != \"0\" ] ; then\n\t#zenity --error --text \"No patchfile given.\"\n\texit 1\nfi\n\ncd - > /dev/null\n\nSUBJECT=`sed -n -e '/^Subject: /p' $PATCH`\nHEADERS=`sed -e '/^Subject: /d' $1`\n\necho \"$SUBJECT\" > $1\necho \"$HEADERS\" >> $1\nsed -e '1,/^$/d' $PATCH >> $1\n\nLAST_DIR=`dirname $PATCH`\nsed -e 's@^LAST_DIR=.*@LAST_DIR='$LAST_DIR'@' $CONFFILE > $CONFFILE\"_\"\nmv $CONFFILE\"_\" $CONFFILE\n"},{"id":"31987","messageId":"Pine.LNX.4.63.0701181615360.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"81b0412b0701180653i7cc0c87md7a9c94a10fa3b24@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T15:16:46Z","receivedAt":"2007-01-18T15:16:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Alex Riesen wrote:\n\n> On 1/18/07, Johannes Schindelin wrote:\n> > > BTW, Junio, how about making the _default_ settable at compile time?\n> > > It'd be reasonable to allow local installations choose to default to what\n> > > they find the most paranoid?\n> > \n> > Better control that with templates.\n> > \n> \n> Do we have a template for config already? I thought they were only for\n> hooks...\n\nThe template mechanism can handle _all_ files in GIT_DIR. Just drop a \n\"config\" into the templates directory, and you're settled.\n\nCiao,\nDscho\n"},{"id":"31989","messageId":"20070118152620.GB15428@spearce.org","threadId":"6410","inReplyTo":"81b0412b0701180641v55987657t331d6a1868dabee0@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-18T15:26:20Z","receivedAt":"2007-01-18T15:26:20Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> don't think so. I _would_ cry seeing how fork(2) gets ported to Windows,\n> and you will, probably... after seeing how it is done in cygwin.\n\nAFAIK there's not a strong reason to keep fork() in Git.\n\nCurrently anytime we fork a process its to perform a small amount\nof file descriptor redirection and then immediately exec some other\nexecutable, or a hook script. In other words we probably could\nconvert all current uses of fork to something like in run-command.c,\nwhich a Windows port could then easily replace using CreateProcess().\n\nBut removing fork isn't worth doing until someone is seriously\ntrying to port Git onto Windows without Cygwin. The current code\nworks on sane OSes and isn't broken, so why fix it?\n \n-- \nShawn.\n"},{"id":"31990","messageId":"8A7AFC0A-470D-4386-A8BD-7DAFEF4E95CD@silverinsanity.com","threadId":"6410","inReplyTo":"45AF6AC6.2060206@op5.se","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-18T15:29:18Z","receivedAt":"2007-01-18T15:29:18Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jan 18, 2007, at 7:40 AM, Andreas Ericsson wrote:\n\n> Junio C Hamano wrote:\n>> Is it common for popular MUAs to have a single command that lets\n>> you specify a file and depending on its suffix paste it inline\n>> or make it an attachment? I had an impression that most have\n>> separate commands for \"read text from file (as opposed to\n>> typing)\" and \"attach a file (of random type, not necessarily and\n>> more often than not text)\".\n>\n> Most have only \"attach\" through various means of point-and-click \n> and drag-and-drop. Thunderbird too lacks the very basic ability of \n> \"include this file as part of the message\". I still haven't been \n> able to find an addon for it that does just that.\n\nThe \"easiest\" way is to open it in an editor and Copy'n'Paste it into \nthe message. Unfortunately, not all clipboards or applications can \nbe trusted not to mangle whitespace. I learned that the hard way \ntrying to use Mail.app to send out patches. I ended up just \ninstalling Mutt. Perhaps I should figure out how this \"git-send- \nemail\" works, although it doesn't appear to support authentication...\n\n~~ Brian\n"},{"id":"31992","messageId":"81b0412b0701180737m49895d24td104b8dd2579de44@mail.gmail.com","threadId":"6410","inReplyTo":"Pine.LNX.4.63.0701181615360.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T15:37:50Z","receivedAt":"2007-01-18T15:37:50Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Johannes Schindelin wrote:\n> > > > BTW, Junio, how about making the _default_ settable at compile time?\n> > > > It'd be reasonable to allow local installations choose to default to what\n> > > > they find the most paranoid?\n> > >\n> > > Better control that with templates.\n> > >\n> >\n> > Do we have a template for config already? I thought they were only for\n> > hooks...\n>\n> The template mechanism can handle _all_ files in GIT_DIR. Just drop a\n> \"config\" into the templates directory, and you're settled.\n\nI'm settled! From now on I will never have any objections regarding\nany defaults as long as they have a config option :)\n"},{"id":"31994","messageId":"625fc13d0701180742t703f4f0ei8847c32fe4e0dcfd@mail.gmail.com","threadId":"6410","inReplyTo":"81b0412b0701180737m49895d24td104b8dd2579de44@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Josh Boyer","fromEmail":"jwboyer@gmail.com","sentAt":"2007-01-18T15:42:53Z","receivedAt":"2007-01-18T15:42:53Z","isPatch":true,"sender":{"key":"jwboyer@gmail.com","avatar":null},"body":"On 1/18/07, Alex Riesen wrote:\n> > The template mechanism can handle _all_ files in GIT_DIR. Just drop a\n> > \"config\" into the templates directory, and you're settled.\n>\n> I'm settled! From now on I will never have any objections regarding\n> any defaults as long as they have a config option :)\n\nWhew. Cool :)\n\nJunio, will this go into git at some point soon-ish? I'm looking\nforward to it...\n\njosh\n"},{"id":"31995","messageId":"20070118154257.GC15428@spearce.org","threadId":"6410","inReplyTo":"81b0412b0701180540x15d20453s3dbc0c061fd06d50@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-18T15:42:57Z","receivedAt":"2007-01-18T15:42:57Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> The _real_ majority of the programmers desperately need a better\n> VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.\n\nYes. But...\n\nYesterday I had a conversation with the software configuration\nmanagement guy at my day-time-pays-the-bills organization.\nThey are seriously looking at Perforce and ClearCase, as these are\nlightyears ahead of what we have already (PVCS Version Manager).\nThey also have 1-800-my-vendor telephone numbers which you can\ncall and scream at someone when the tool corrupts its internal\ndatabase[*1*], or when you cannot figure out what the \"Checkout\"\naction in the context menu does[*2*].\n\nHowever my fellow developers and I use Git. We export our changes\nout to PVCS Version Manager via an *ugly* Perl script that I would\nnever actually wish on anyone (which is one reason why its not\ncontributed as git-pvcsexport). Configuration management guy won't\neven look at Git's real strengths as it lacks the all-important\n1-800-git-help[*3*] phone number.\n\nYesterday we spent 4 half-man-days (4 developers working together\nall morning) trying to get a configuration of random files from\nPVCS Version Manager which compiled. In Git this would have been as\nsimple as merging the two topics that management wanted moved to the\nnext level of testing. But since our organization doesn't actually\nuse Git and multiple topics affected the same files, well, yea, it\nwas a mess. Unfortunately calling 1-800-my-vendor yields a \"don't do\nthat\" from our vendor and nothing more in support. I'm very glad\nwe pay them for the privilege of having a 1-800-my-vendor phone\nnumber in our rolodex. Yesterday it cost us over $1600 in labor.\n\n> Yes. For me and you. One of my coworkers knows nothing about patches,\n> but wants (and perfectly able to) review my code. He has usable brains\n> and is able to figure out what \"+\" and \"-\" is (he has, by now). He hasn't\n> even realized that it was an automatically generated information, as\n> I sent a patch to him first time, thought it was just a funny way to\n> document changes (and was surprised when I told him a patch can be\n> applied automatically, even if the original file is not exactly the same).\n> But he is a typical windows-trained programmer.\n\nI work with a few people who would rather copy and paste their\nchanged parts into an email, then color them with pretty colors\nlike red, green, blue, black, orange in Outlook (and all in the\nsame email too). These then get sent to me for code review.\n\nPrior to us using Git it may make some sense, as we did not have\na diff tool available. Now that everyone is using Git and working\nin isolated topic branches (and doing very well with that concept)\nI still get these emails. People seem to have an easy time grasping\nthe idea that Git is tracking their changes and when combined with\nmy git-pvcsexport (see above) it just Does The Right Thing(tm)\nlater on. But they have a hard time grasping the idea that Git can\nexport these as a diff, or that they could just push their topic\nbranch to me so I can pop it open in gitk. *sigh*\n\n\n[*1*] This has happened to me with Perforce more than once. Not a\n happy thought. Never with Git.\n\n[*2*] Yes, really, some of our version control users have difficulty\n grasping a concept like \"checkout\". They *definately* have\n an issue with Git's \"checkout -b\" concept.\n\n[*3*] Already taken. Oddly enough by a company that could almost\n be considered to be a competiter to my day-time-pays-the-bills\n organization.\n \n-- \nShawn.\n"},{"id":"31997","messageId":"81b0412b0701180752x1664f661o17ce78a7024590f3@mail.gmail.com","threadId":"6410","inReplyTo":"20070118152620.GB15428@spearce.org","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T15:52:40Z","receivedAt":"2007-01-18T15:52:40Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Shawn O. Pearce wrote:\n> > don't think so. I _would_ cry seeing how fork(2) gets ported to Windows,\n> > and you will, probably... after seeing how it is done in cygwin.\n>\n> AFAIK there's not a strong reason to keep fork() in Git.\n>\n> Currently anytime we fork a process its to perform a small amount\n> of file descriptor redirection and then immediately exec some other\n> executable, or a hook script. In other words we probably could\n> convert all current uses of fork to something like in run-command.c,\n> which a Windows port could then easily replace using CreateProcess().\n\nI count 17 instances (excluding run_command). At least fetch-pack\nis not trivial (the sideband code. Could be done in a thread, which\nis not portable just as well).\n\n> But removing fork isn't worth doing until someone is seriously\n> trying to port Git onto Windows without Cygwin. The current code\n> works on sane OSes and isn't broken, so why fix it?\n\nRight.\n"},{"id":"31998","messageId":"81b0412b0701180805r276fcfaq2c1582ab8e82515b@mail.gmail.com","threadId":"6410","inReplyTo":"20070118154257.GC15428@spearce.org","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-18T16:05:52Z","receivedAt":"2007-01-18T16:05:52Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/07, Shawn O. Pearce wrote:\n> > The _real_ majority of the programmers desperately need a better\n> > VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.\n>\n> Yes. But...\n>\n> Yesterday I had a conversation with the software configuration\n> management guy at my day-time-pays-the-bills organization.\n> They are seriously looking at Perforce and ClearCase, as these are\n> lightyears ahead of what we have already (PVCS Version Manager).\n> They also have 1-800-my-vendor telephone numbers which you can\n> call and scream at someone when the tool corrupts its internal\n> database[*1*], or when you cannot figure out what the \"Checkout\"\n> action in the context menu does[*2*].\n>\n> However my fellow developers and I use Git. We export our changes\n> out to PVCS Version Manager via an *ugly* Perl script that I would\n> never actually wish on anyone (which is one reason why its not\n> contributed as git-pvcsexport). Configuration management guy won't\n> even look at Git's real strengths as it lacks the all-important\n> 1-800-git-help[*3*] phone number.\n\nOf course, he is the who'll do the yelling. It's you who'll need support.\nStandard Perforce replies: \"it is not supported\" (if you need branches\nas in Git), or \"we will probably look into it\" (if you point them to a bug.\nThey never really do). Worst performance in the industry, too.\n\nClearCase had a sleep(6 /*sec*/) before writing a file in local checkouts\non linux, for whatever reason :) It at least knows about oriented graphs.\n"},{"id":"31999","messageId":"45AF9BD4.B0E44CB6@eudaptics.com","threadId":"6410","inReplyTo":"20070118152620.GB15428@spearce.org","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-01-18T16:09:56Z","receivedAt":"2007-01-18T16:09:56Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> AFAIK there's not a strong reason to keep fork() in Git.\n> \n> Currently anytime we fork a process its to perform a small amount\n> of file descriptor redirection and then immediately exec some other\n> executable, or a hook script. In other words we probably could\n> convert all current uses of fork to something like in run-command.c,\n> which a Windows port could then easily replace using CreateProcess().\n> \n> But removing fork isn't worth doing until someone is seriously\n> trying to port Git onto Windows without Cygwin. The current code\n> works on sane OSes and isn't broken, so why fix it?\n\nI'm doing just that (MinGW port).\n\nI've come up with a function spawnvpe_pipe(), which hides all the scary\ndetails of fork+exec with dup2's and close's. It could probably easily\nbe merged into run_command(), but I haven't tried that, yet.\n\nI'll try to push out what I have to repo.or.cz over the weekend. \n\n-- Hannes\n"},{"id":"32003","messageId":"45AFA083.9050004@op5.se","threadId":"6410","inReplyTo":"20070118154257.GC15428@spearce.org","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-18T16:29:55Z","receivedAt":"2007-01-18T16:29:55Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> Alex Riesen wrote:\n> \n> However my fellow developers and I use Git. We export our changes\n> out to PVCS Version Manager via an *ugly* Perl script that I would\n> never actually wish on anyone (which is one reason why its not\n> contributed as git-pvcsexport). Configuration management guy won't\n> even look at Git's real strengths as it lacks the all-important\n> 1-800-git-help[*3*] phone number.\n> \n\nWould a +46-31 number work? If so, you could give me a call when you're\nhaving trouble. I'd probably end up asking the list, or bribing Junio\nwith beer to answer for me, but the fee would be low (how much is a\ndozen beers in Japan?), so perhaps it'd be worth it ;-)\n\nOn a serious note, it's probably about time the world saw its first\ncommercial git support company. It's legal to package and sell GPL'd\ncode. Many companies have already proven that it can be a very\nlucrative business.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"32004","messageId":"20070118165107.GF15428@spearce.org","threadId":"6410","inReplyTo":"45AFA083.9050004@op5.se","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-18T16:51:08Z","receivedAt":"2007-01-18T16:51:08Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andreas Ericsson wrote:\n> Would a +46-31 number work? If so, you could give me a call when you're\n> having trouble. I'd probably end up asking the list, or bribing Junio\n> with beer to answer for me, but the fee would be low (how much is a\n> dozen beers in Japan?), so perhaps it'd be worth it ;-)\n\nHeh. The thing is, with me \"on staff\" I doubt you can get much\nbetter support. I know Git very well, almost as well as Linus,\nJunio, Nico, and Johannes (sorry, no particular order there).\nWhat I don't know off the top of my head, I know where the source\ncode for it is, and I can read and understand it rather quickly.\n\nWhen something breaks, I can usually fix it myself, and that usually\nresults in a patch to Junio just hours after I discover the problem.\nMost of the time the patch is worthy of inclusion and Junio picks\nit up. You can't get that kind of response from a commerical vendor,\nat least not without forking over bucket loads of cash first.\n\nThe problem is, the organization has strict rules about recommending\nyourself as a vendor. But recommending a guy half way around the\nworld who works for beer is probably in compliance. :-)\n \n> On a serious note, it's probably about time the world saw its first\n> commercial git support company. It's legal to package and sell GPL'd\n> code. Many companies have already proven that it can be a very\n> lucrative business.\n\nI've thought about doing this myself. I'm just so short on time\nthat developing a business providing support would probably push me\nway over the edge. Ideally I'd love to have such a venture make its\nmoney off support contracts and a small markup on dead-tree forms of\nopen-source Git documentation. I'd also love to see such a venture\nbe able to support a Git developer or two full-time, making sure that\nall of their work is getting folded back into the main git.git tree.\nWhich of course implies they can't be heading off in directions\nthat the rest of the group finds useless/pointless/stupid/etc.\n\nWishful thinking. Back to reality.\n\n-- \nShawn.\n"},{"id":"32005","messageId":"45AFA855.6050804@op5.se","threadId":"6410","inReplyTo":"20070118165107.GF15428@spearce.org","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-18T17:03:17Z","receivedAt":"2007-01-18T17:03:17Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> Andreas Ericsson wrote:\n>> Would a +46-31 number work? If so, you could give me a call when you're\n>> having trouble. I'd probably end up asking the list, or bribing Junio\n>> with beer to answer for me, but the fee would be low (how much is a\n>> dozen beers in Japan?), so perhaps it'd be worth it ;-)\n> \n> Heh. The thing is, with me \"on staff\" I doubt you can get much\n> better support. I know Git very well, almost as well as Linus,\n> Junio, Nico, and Johannes (sorry, no particular order there).\n> What I don't know off the top of my head, I know where the source\n> code for it is, and I can read and understand it rather quickly.\n> \n\nYa, I knows. :)\n\n> When something breaks, I can usually fix it myself, and that usually\n> results in a patch to Junio just hours after I discover the problem.\n> Most of the time the patch is worthy of inclusion and Junio picks\n> it up. You can't get that kind of response from a commerical vendor,\n> at least not without forking over bucket loads of cash first.\n> \n> The problem is, the organization has strict rules about recommending\n> yourself as a vendor. But recommending a guy half way around the\n> world who works for beer is probably in compliance. :-)\n> \n\nThat was my devilishly clever plan; To provide support to someone who\nknows the thing I'm supposed to support a lot better than myself, while\ngetting some free beer in the process ;-)\n\n>> On a serious note, it's probably about time the world saw its first\n>> commercial git support company. It's legal to package and sell GPL'd\n>> code. Many companies have already proven that it can be a very\n>> lucrative business.\n> \n> I've thought about doing this myself. I'm just so short on time\n> that developing a business providing support would probably push me\n> way over the edge. Ideally I'd love to have such a venture make its\n> money off support contracts and a small markup on dead-tree forms of\n> open-source Git documentation. I'd also love to see such a venture\n> be able to support a Git developer or two full-time, making sure that\n> all of their work is getting folded back into the main git.git tree.\n> Which of course implies they can't be heading off in directions\n> that the rest of the group finds useless/pointless/stupid/etc.\n> \n> Wishful thinking. Back to reality.\n> \n\nThis is a case where \"Think Big\" isn't enough, and you need to \"Think\nBigger\". Don't settle for shipping help-docs on git and answering the\nphone. Sell pre-packaged versions of git, with a pre-installed Linux\nserver with raided disks and a nifty backup-solution (just sell a second\nserver and use an update-hook to replicate everything to that one, then\nyou're done). You could easily charge up to $2,500 / user for providing\n\"A fully integrated VCS / backup solution, with full failover to ensure\n100% efficiency in your day-to-day job\". Tack on another 10k for the\ntwo servers and another 1k / dev to go to a training seminar and you're\ngood to go.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"32012","messageId":"46a038f90701181119v47d24b28n92973c60ae74e0e7@mail.gmail.com","threadId":"6410","inReplyTo":"45AFA083.9050004@op5.se","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-01-18T19:19:44Z","receivedAt":"2007-01-18T19:19:44Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/19/07, Andreas Ericsson wrote:\n> On a serious note, it's probably about time the world saw its first\n> commercial git support company. It's legal to package and sell GPL'd\n> code. Many companies have already proven that it can be a very\n> lucrative business.\n\n\nAt Catalyst (~70 perl/java/php/c/c++ developers, mostly foss\ndevelopment) we have switched internally to git for 80% of our active\nprojects and we do offer commercial support for a couple of clients.\nIt's not the only thing we do for those clients, but if an\norganisation needed specifically support for git, we can help.\n\nWe aren't pushing/packaging/selling it because it doesn't work well\nthat way (for us at least). When it's about new tools, we prefer to\nwork with people who already know what they want ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"32013","messageId":"45AFCAB1.8010903@midwinter.com","threadId":"6410","inReplyTo":"81b0412b0701180752x1664f661o17ce78a7024590f3@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-18T19:29:53Z","receivedAt":"2007-01-18T19:29:53Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Alex Riesen wrote:\n> I count 17 instances (excluding run_command). At least fetch-pack\n> is not trivial (the sideband code. Could be done in a thread, which\n> is not portable just as well).\n\nI looked at that briefly a while ago -- at the prompting of a Windows \ndeveloper friend of mine who has some interest in git -- and it seemed \nlike the best thing for portability to non-fork()ing systems would \nprobably be a refactor. It looked to me like it'd be possible to \nreorganize the code such that it'd work all in one process with no \nthreads or forking or anything. Not *trivial*, mind you, but possible. \nThere's nothing in the code path that I saw (I didn't analyze it \nsuper-thoroughly) that looked like it actually needed to run in parallel.\n\nIMO it's worth doing at some point post-1.5.0 simply because it means \none less hurdle for someone who's looking to port Git to Windows. Plus \nit'll probably make the code slightly more efficient even on Linux and \nfriends; there'd be less context-switching latency.\n\n From my brief look, that was the only nontrivial use of fork(). Almost \nall of the rest are simple fork/exec pairs.\n\nOf course, the bigger hurdle for a native Windows port is all the shell \nscripts. Mercurial solves that by using Python for all its scripts, \nwhich at least has a native Windows version that can be installed. I \nwonder if git will/should eventually move its remaining shell scripts to \nPerl for that reason, Perl being git's de facto non-shell scripting \nlanguage of choice.\n\n-Steve\n"},{"id":"32014","messageId":"46a038f90701181130p72e11368sbe61de9ceb0eada3@mail.gmail.com","threadId":"6410","inReplyTo":"20070118165107.GF15428@spearce.org","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-01-18T19:30:07Z","receivedAt":"2007-01-18T19:30:07Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/19/07, Shawn O. Pearce wrote:\n> Wishful thinking. Back to reality.\n\nNot necessarily ;-) but I'm not sure if the time is right for an\nindependend services company doing _only_ git.\n\nHowever, git is the kind of SCM that a big distro needs to keep track\nof all their \"vendor branches\" or \"patches against upstream\". Ubuntu\npays at least one full-time SCM developer, Martin Pool, to maintain\nBazaar NG and accesory tools.\n\nIIRC MySQL was looking quite seriously to drop BK and with the savings\nin licenses, can surely affort to hire a GIT guru to \"train the\ntrainer\", solve problems/bugs and write internal support tools. Others\nwill follow. It shouldn't be too hard to find the right place.\n\nOr a large FOSS services focused company (like Catalyst) that uses git\nand offers support as part of a larger bundle. (we're hiring,\nand putting git hackery in your cv is a winner). There are\nplenty of gaps and places for git hackers.\n\ncheers\n\n\nmartin\n"},{"id":"32016","messageId":"Pine.LNX.4.63.0701182053090.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"45AFCAB1.8010903@midwinter.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T19:57:31Z","receivedAt":"2007-01-18T19:57:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Steven Grimm wrote:\n\n> I looked at that briefly a while ago -- at the prompting of a Windows \n> developer friend of mine who has some interest in git -- and it seemed \n> like the best thing for portability to non-fork()ing systems would \n> probably be a refactor. It looked to me like it'd be possible to \n> reorganize the code such that it'd work all in one process with no \n> threads or forking or anything. Not *trivial*, mind you, but possible. \n> There's nothing in the code path that I saw (I didn't analyze it \n> super-thoroughly) that looked like it actually needed to run in \n> parallel.\n\nssh transport comes to mind, as well as paging functionality. Sometimes we \nfork() to catch out-of-memory errors more gracefully.\n\n> Of course, the bigger hurdle for a native Windows port is all the shell \n> scripts. Mercurial solves that by using Python for all its scripts, \n> which at least has a native Windows version that can be installed. I \n> wonder if git will/should eventually move its remaining shell scripts to \n> Perl for that reason, Perl being git's de facto non-shell scripting \n> language of choice.\n\nYeah, sure. We had no problems with Perl ;-)\n\nSeriously, IMHO bash is a smaller dependency: here you can at least rely \non which extensions are present (none), and which path-name munging is \npresent on Windows (/c/windows).\n\nNo, the best is not to migrate shell scripts to Perl, but to C.\n\nCiao,\nDscho\n"},{"id":"32017","messageId":"Pine.LNX.4.63.0701182101230.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6410","inReplyTo":"625fc13d0701180742t703f4f0ei8847c32fe4e0dcfd@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T20:03:55Z","receivedAt":"2007-01-18T20:03:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Josh Boyer wrote:\n\n> On 1/18/07, Alex Riesen wrote:\n> > > The template mechanism can handle _all_ files in GIT_DIR. Just drop a\n> > > \"config\" into the templates directory, and you're settled.\n> > \n> > I'm settled! From now on I will never have any objections regarding\n> > any defaults as long as they have a config option :)\n> \n> Whew. Cool :)\n> \n> Junio, will this go into git at some point soon-ish? I'm looking\n> forward to it...\n\nYou mean the templates mechanism? Has been in git since\n\n\tv0.99.4~43 (Tue Aug 2 16:45:21 2005 -0700)\n\nCiao,\nDscho\n"},{"id":"32018","messageId":"625fc13d0701181212r67a9f132k7d9bed8e9fc51d29@mail.gmail.com","threadId":"6410","inReplyTo":"Pine.LNX.4.63.0701182101230.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Josh Boyer","fromEmail":"jwboyer@gmail.com","sentAt":"2007-01-18T20:12:15Z","receivedAt":"2007-01-18T20:12:15Z","isPatch":true,"sender":{"key":"jwboyer@gmail.com","avatar":null},"body":"On 1/18/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Thu, 18 Jan 2007, Josh Boyer wrote:\n>\n> > On 1/18/07, Alex Riesen wrote:\n> > > > The template mechanism can handle _all_ files in GIT_DIR. Just drop a\n> > > > \"config\" into the templates directory, and you're settled.\n> > >\n> > > I'm settled! From now on I will never have any objections regarding\n> > > any defaults as long as they have a config option :)\n> >\n> > Whew. Cool :)\n> >\n> > Junio, will this go into git at some point soon-ish? I'm looking\n> > forward to it...\n>\n> You mean the templates mechanism? Has been in git since\n\nNo, I mean a switch to using \".patch\" as the default and the option to\nspecify your own suffix. The actual reason this thread was started :)\n\njosh\n"},{"id":"32052","messageId":"eoq5es$bto$1@sea.gmane.org","threadId":"6410","inReplyTo":"81b0412b0701180641v55987657t331d6a1868dabee0@mail.gmail.com","subject":"Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-19T10:11:14Z","receivedAt":"2007-01-19T10:11:14Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Alex Riesen wrote:\n\n> BTW, Junio, how about making the _default_ settable at compile time?\n> It'd be reasonable to allow local installations choose to default to what\n> they find the most paranoid?\n\nYou can always modify templates.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}