{"thread":{"id":"15126","subject":"[PATCH] allow user aliases for the --author parameter","startedAt":"2008-08-21T09:19:41Z","lastAt":"2008-08-28T21:36:43Z","messageCount":32,"participants":["Michael J Gruber","Miklos Vajna","Alex Riesen","Jeff King","Junio C Hamano","Pedro Melo"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"87959","messageId":"g8jbvd$18k$1@ger.gmane.org","threadId":"15126","inReplyTo":null,"subject":"[PATCH] allow user aliases for the --author parameter","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-21T09:19:41Z","receivedAt":"2008-08-21T09:19:41Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"This allows the use of author abbreviations when specifying commit\nauthors via the --author option to git commit. \"--author=$key\" is\nresolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\nconfig.\n\nSigned-off-by: Michael J Gruber \n---\nIn an ideal word, all my collaborators would exchange changes as git \npatches (or even via pull/push). In the real world, they send new\nversions which I integrate (after dealing with their whitespace and encoding changes...).\nTherefore, being able to say \n\"git commit --author=mickey\"\nand having git translate \"mickey\" into \"Mickey Mouse \"\nis a real time saver. The patch accomplishes this by reading config keys \"user.mickey.name\" and \"user.mickey.email\" when encountering an \n--author argument without \"<>\".\n\nIf there's interest in this patch I'll follow up with a documentation patch.\n\nThe \"--committer\" argument to git commit is not treated because I don't\nconsider it worthwhile.\n\nNote that the implementation is different from git-svn's author file on\npurpose because it serves a different purpose.\n\nMichael\n\nP.S.: That's my first patch here. Yes, I've read Doc/SubmittingPatches.\nSo, if something's wrong, please be gentle but not overly so ;) \n\n builtin-commit.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++-\n 1 files changed, 64 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 649c8be..d90e2f4 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -53,6 +53,12 @@ static char *author_name, *author_email, *author_date;\n static int all, edit_flag, also, interactive, only, amend, signoff;\n static int quiet, verbose, no_verify, allow_empty;\n static char *untracked_files_arg;\n+struct user {\n+\tchar *name, *full_name, *email;\n+};\n+static struct user **users;\n+static int users_alloc;\n+static int users_nr;\n /*\n * The default commit message cleanup mode will remove the lines\n * beginning with # (shell comments) and leading and trailing\n@@ -406,6 +412,7 @@ static const char sign_off_header[] = \"Signed-off-by: \";\n static void determine_author_info(void)\n {\n \tchar *name, *email, *date;\n+\tint i;\n \n \tname = getenv(\"GIT_AUTHOR_NAME\");\n \temail = getenv(\"GIT_AUTHOR_EMAIL\");\n@@ -429,10 +436,22 @@ static void determine_author_info(void)\n \t\tdate = xstrndup(rb + 2, eol - (rb + 2));\n \t}\n \n+\tauthor_date = date;\n+\n \tif (force_author) {\n \t\tconst char *lb = strstr(force_author, \" <\");\n \t\tconst char *rb = strchr(force_author, '>');\n \n+\t\tif (!lb && !rb) {\n+\t\t\tfor (i=0; i < users_nr; i++) {\n+\t\t\t\tif (!strcmp(force_author, users[i]->name)) {\n+\t\t\t\t\tauthor_name = users[i]->full_name;\n+\t\t\t\t\tauthor_email = users[i]->email;\n+\t\t\t\t\treturn;\n+\t\t\t\t}\n+\t\t\t}\n+\t\t}\n+\n \t\tif (!lb || !rb)\n \t\t\tdie(\"malformed --author parameter\");\n \t\tname = xstrndup(force_author, lb - force_author);\n@@ -441,7 +460,6 @@ static void determine_author_info(void)\n \n \tauthor_name = name;\n \tauthor_email = email;\n-\tauthor_date = date;\n }\n \n static int prepare_to_commit(const char *index_file, const char *prefix)\n@@ -888,11 +906,56 @@ static void print_summary(const char *prefix, const unsigned char *sha1)\n \t}\n }\n \n+static struct user *make_user(const char *name, int len)\n+{\n+\tstruct user *ret;\n+\tint i;\n+\n+\tfor (i = 0; i < users_nr; i++) {\n+\t\tif (len ? (!strncmp(name, users[i]->name, len) &&\n+\t\t\t !users[i]->name[len]) :\n+\t\t !strcmp(name, users[i]->name))\n+\t\t\treturn users[i];\n+\t}\n+\n+\tALLOC_GROW(users, users_nr + 1, users_alloc);\n+\tret = xcalloc(1, sizeof(struct user));\n+\tusers[users_nr++] = ret;\n+\tif (len)\n+\t\tret->name = xstrndup(name, len);\n+\telse\n+\t\tret->name = xstrdup(name);\n+\n+\treturn ret;\n+}\n+\n static int git_commit_config(const char *k, const char *v, void *cb)\n {\n+\tconst char *name;\n+\tconst char *subkey;\n+\tstruct user *user;\n+\n \tif (!strcmp(k, \"commit.template\"))\n \t\treturn git_config_string(&template_file, k, v);\n \n+\tif (!prefixcmp(k, \"user.\")) {\n+\t\tname = k + 5;\n+\t\tsubkey = strrchr(name, '.');\n+\t\tif (!subkey)\n+\t\t\treturn 0;\n+\t\tuser = make_user(name, subkey - name);\n+\t\tif (!strcmp(subkey, \".name\")) {\n+\t\t\tif (!v)\n+\t\t\t\treturn config_error_nonbool(k);\n+\t\t\tuser->full_name = xstrdup(v);\n+\t\t} else if (!strcmp(subkey, \".email\")) {\n+\t\t\tif (!v)\n+\t\t\t\treturn config_error_nonbool(k);\n+\t\t\tuser->email = xstrdup(v);\n+\t\t}\n+\t\treturn 0;\n+\t}\n+\n \treturn git_status_config(k, v, cb);\n }\n \n-- \n1.6.0\n"},{"id":"87980","messageId":"20080821134946.GR23800@genesis.frugalware.org","threadId":"15126","inReplyTo":"g8jbvd$18k$1@ger.gmane.org","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-08-21T13:49:47Z","receivedAt":"2008-08-21T13:49:47Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, Aug 21, 2008 at 11:19:41AM +0200, Michael J Gruber wrote:\n> If there's interest in this patch I'll follow up with a documentation patch.\n\nSee http://article.gmane.org/gmane.comp.version-control.git/92913.\n"},{"id":"87988","messageId":"48AD7C06.50501@fastmail.fm","threadId":"15126","inReplyTo":"20080821134946.GR23800@genesis.frugalware.org","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-21T14:30:30Z","receivedAt":"2008-08-21T14:30:30Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Miklos Vajna venit, vidit, dixit 21.08.2008 15:49:\n> On Thu, Aug 21, 2008 at 11:19:41AM +0200, Michael J Gruber wrote:\n>> If there's interest in this patch I'll follow up with a documentation patch.\n> \n> See http://article.gmane.org/gmane.comp.version-control.git/92913.\n\nI've read the post you quote but I'm not sure you've read that AND my\npost. I clearly described/documented what my patch does and why I think\nit's useful, in the way it's often done here: after the commit message\nand before the diffstat. It is documented (as required in the post you\ncite), it just doesn't contain a documentation patch.\n\nDocumentation/SubmittingPatches in all its length doesn't contain the\nrequirement you're reading into Junio's post. Maybe it should, if that's\nwhat is meant.\n\nMichael\n"},{"id":"88013","messageId":"20080821174118.GB5119@blimp.local","threadId":"15126","inReplyTo":"g8jbvd$18k$1@ger.gmane.org","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-21T17:41:18Z","receivedAt":"2008-08-21T17:41:18Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Michael J Gruber, Thu, Aug 21, 2008 11:19:41 +0200:\n> This allows the use of author abbreviations when specifying commit\n> authors via the --author option to git commit. \"--author=$key\" is\n> resolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\n> config.\n\nIsn't there existing well-known formats for mail aliases?\nFor instance, Mutt uses simple text file:\n\n alias nickname1 Author Name \n alias nickname2 \"Author Name 2\" \n\nI don't know how well-known this is, but is surely more known than\ngit's config (and there are aliases in that format already).\nMaybe just reference such files in git's config?\n"},{"id":"88014","messageId":"20080821174915.GC5119@blimp.local","threadId":"15126","inReplyTo":"20080821174118.GB5119@blimp.local","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-21T17:49:16Z","receivedAt":"2008-08-21T17:49:16Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Alex Riesen, Thu, Aug 21, 2008 19:41:18 +0200:\n> Michael J Gruber, Thu, Aug 21, 2008 11:19:41 +0200:\n> > This allows the use of author abbreviations when specifying commit\n> > authors via the --author option to git commit. \"--author=$key\" is\n> > resolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\n> > config.\n> \n> Isn't there existing well-known formats for mail aliases?\n> For instance, Mutt uses simple text file:\n> \n> alias nickname1 Author Name \n> alias nickname2 \"Author Name 2\" \n> \n> I don't know how well-known this is, but is surely more known than\n> git's config (and there are aliases in that format already).\n> Maybe just reference such files in git's config?\n> \n\nOh, and you may consider using .mailmap files (look into the Git's\none for example): the user part of mail address is very often a good\nalias (and sometimes famous nickname) of a person: junio, tytso,\ndavem, alan, viro, hpa... You'll have to define some rules for\nduplications, of course (first wins seems to be popular).\n"},{"id":"88025","messageId":"20080821200255.GB27705@coredump.intra.peff.net","threadId":"15126","inReplyTo":"g8jbvd$18k$1@ger.gmane.org","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-21T20:02:55Z","receivedAt":"2008-08-21T20:02:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 21, 2008 at 11:19:41AM +0200, Michael J Gruber wrote:\n\n> This allows the use of author abbreviations when specifying commit\n> authors via the --author option to git commit. \"--author=$key\" is\n> resolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\n> config.\n\nThis seems like a reasonable feature to me, though two high-level\nquestions:\n\n - Is it worth supporting external alias sources, as Alex mentioned? I\n think that would make more sense for many people. Even if you are\n not personally interested in writing it, it would be nice to keep it\n in mind as a future expansion when doing this work. For example,\n maybe it makes more sense for the config to point to a (type, file)\n pair instead of placing directly into the config. Or maybe this\n should just live in conjunction with that feature, if somebody cares\n to implement it.\n\n - Is user.$key the right namespace? It precludes a few particular\n aliases, and it might clash with future user.* config. Perhaps\n user.alias.* would be a better place (or, as above, just referencing\n an external file).\n\n - git-send-email already looks at some alias files. Maybe this is an\n opportunity to refactor and centralize (although perhaps it is not\n worth the effort, because of the different implementation\n languages).\n\n> ---\n> In an ideal word, all my collaborators would exchange changes as git \n> patches (or even via pull/push). In the real world, they send new\n> versions which I integrate (after dealing with their whitespace and encoding changes...).\n> Therefore, being able to say \n> \"git commit --author=mickey\"\n> and having git translate \"mickey\" into \"Mickey Mouse \"\n> is a real time saver. The patch accomplishes this by reading config keys \"user.mickey.name\" and \"user.mickey.email\" when encountering an \n> --author argument without \"<>\".\n\nThis justification should probably go into the commit message, not the\ncover letter. When you are writing it, think about the reader who will\nbisect or blame to your commit a year from now. Will they want to see\njust _what_ you did, or _why_ you did it?\n\n> If there's interest in this patch I'll follow up with a documentation patch.\n\nI think Miklos already yelled at you for this. The message he referenced\ndoesn't quite apply, because you did include some discussion of the\n\"why\". The reason I think Junio (and other reviewers) find the \"I'll\ndocument this if it is accepted\" so frustrating is that it puts them in\nan awkward position.\n\nWhen reviewing, you are trying to say \"is this patch OK?\". And clearly\nit isn't, because it lacks documentation. Now Junio could queue your\npatch and wait for the documentation, but sometimes the followup doc\npatches aren't as easily forthcoming, and then he has to deal with it\nlater.\n\nFurthermore, it is sort of a good faith effort. It shows that you put\nthe work into cleaning up the patch for presenting to the community,\nwhich encourages the community to take a look. Saying \"this is half of\nthe work, and I will do the other half if you like this\" makes reviewers\nwonder how cleaned up and ready the patch is.\n\nAll of that being said, I think in this instance it is less about the\npatch and more in the words you picked. If you said \"I am thinking about\nthis feature, and here is how I think the interface should work, and\nhere is the patch I have so far. I don't want to document the interface\nuntil it is settled, so please comment on that and I will work up a\nfinal patch\" then that would have gone over very well. But as it\nhappens, you chose the magic pet peeve words. ;)\n\n> The \"--committer\" argument to git commit is not treated because I don't\n> consider it worthwhile.\n\nIf you are introducing a new source of alias mappings, it would make\nsense to me to support it everywhere for the sake of consistency. That\nmeans --committer should look at it, too (and should only be a few\nlines, I would think), and probably git-send-email.\n\n> P.S.: That's my first patch here. Yes, I've read Doc/SubmittingPatches.\n> So, if something's wrong, please be gentle but not overly so ;)\n\nI hope this is the right amount of gentleness. ;)\n\n> --- a/builtin-commit.c\n> +++ b/builtin-commit.c\n> @@ -53,6 +53,12 @@ static char *author_name, *author_email, *author_date;\n> static int all, edit_flag, also, interactive, only, amend, signoff;\n> static int quiet, verbose, no_verify, allow_empty;\n> static char *untracked_files_arg;\n> +struct user {\n> +\tchar *name, *full_name, *email;\n> +};\n\nOthers may disagree, but style-wise I think we usually put each struct\nmember on its own line.\n\n> \tif (force_author) {\n> \t\tconst char *lb = strstr(force_author, \" <\");\n> \t\tconst char *rb = strchr(force_author, '>');\n> \n> +\t\tif (!lb && !rb) {\n> +\t\t\tfor (i=0; i < users_nr; i++) {\n\nStyle: \"i = 0\"\n\n> +\t\t\t\tif (!strcmp(force_author, users[i]->name)) {\n> +\t\t\t\t\tauthor_name = users[i]->full_name;\n> +\t\t\t\t\tauthor_email = users[i]->email;\n> +\t\t\t\t\treturn;\n> +\t\t\t\t}\n\n\nI haven't traced all of the uses of author_name and author_email, but\nall of the other codepaths seem to allocate a new string, whereas this\nuses the existing strings. Is this going to accidentally free() from the\nusers list, or are we just leaking those other strings now?\n\n> +\tALLOC_GROW(users, users_nr + 1, users_alloc);\n\nYay, a first-time submitter bothered to use ALLOC_GROW! :)\n\n> +\tret = xcalloc(1, sizeof(struct user));\n> +\tusers[users_nr++] = ret;\n> +\tif (len)\n> +\t\tret->name = xstrndup(name, len);\n> +\telse\n> +\t\tret->name = xstrdup(name);\n> +\n> +\treturn ret;\n> +}\n\nThis is the not the most git-ish way of using the config[1]. Usually we\navoid reading big lists into memory, but rather just call git_config\nwith the appropriate callback when we find we need to look up the user\nalias.\n\n[1] However, I don't necessarily agree with this. We can end up parsing\nthe config (which may be split across 3 files) several times per\ncommand, so it is probably better to just parse and store it in one go.\nSo I will let Junio comment on the preferred method.\n\n-Peff\n"},{"id":"88089","messageId":"7vljypd1ho.fsf@gitster.siamese.dyndns.org","threadId":"15126","inReplyTo":"20080821200255.GB27705@coredump.intra.peff.net","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-22T06:09:55Z","receivedAt":"2008-08-22T06:09:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Aug 21, 2008 at 11:19:41AM +0200, Michael J Gruber wrote:\n>\n>> This allows the use of author abbreviations when specifying commit\n>> authors via the --author option to git commit. \"--author=$key\" is\n>> resolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\n>> config.\n>\n> This seems like a reasonable feature to me, though two high-level\n> questions:\n\nIn short, I'm in agreement with almost everything you said in your\nresponse, in that I think (1) this is a reasonable thing to want to do,\n(2) this should use an external mail-alias file, not set of in-config\nvalues, possibly sharing the database with send-email, (3) committer\nshould be treated the same way (shouldn't the effort be the same?\notherwise there is something wrong in the existing code structure).\n\n>> In an ideal word, all my collaborators would exchange changes as git \n>> ...\n>> --author argument without \"<>\".\n>\n> This justification should probably go into the commit message, not the\n> cover letter. When you are writing it, think about the reader who will\n> bisect or blame to your commit a year from now. Will they want to see\n> just _what_ you did, or _why_ you did it?\n\nAbsolutely. What the change does is already visible in \"log -p\". The\nreason behind the change, \"Why\", is much more important, and Michael's\njustification was very well written. It should have been in the proposed\ncommit log message.\n"},{"id":"88106","messageId":"48AE786C.20201@fastmail.fm","threadId":"15126","inReplyTo":"20080821200255.GB27705@coredump.intra.peff.net","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-22T08:27:24Z","receivedAt":"2008-08-22T08:27:24Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"First of all: Thanks for all your responses. I think I've learned a lot\nthrough them, and hopefully I'll be able to give evidence with an\nupcoming patch...\n\nJeff King venit, vidit, dixit 21.08.2008 22:02:\n> On Thu, Aug 21, 2008 at 11:19:41AM +0200, Michael J Gruber wrote:\n> \n>> This allows the use of author abbreviations when specifying commit \n>> authors via the --author option to git commit. \"--author=$key\" is \n>> resolved by looking up \"user.$key.name\" and \"user.$key.email\" in\n>> the config.\n> \n> This seems like a reasonable feature to me, though two high-level \n> questions:\n> \n> - Is it worth supporting external alias sources, as Alex mentioned? I\n> think that would make more sense for many people. Even if you are \n> not personally interested in writing it, it would be nice to keep it \n> in mind as a future expansion when doing this work. For example, \n> maybe it makes more sense for the config to point to a (type, file) \n> pair instead of placing directly into the config. Or maybe this \n> should just live in conjunction with that feature, if somebody cares \n> to implement it.\n> \n> - Is user.$key the right namespace? It precludes a few particular \n> aliases, and it might clash with future user.* config. Perhaps \n> user.alias.* would be a better place (or, as above, just referencing \n> an external file).\n> \n> - git-send-email already looks at some alias files. Maybe this is an \n> opportunity to refactor and centralize (although perhaps it is not \n> worth the effort, because of the different implementation languages).\n\nThere's also git svn.\nI think all of these serve different purposes, and have different\ntypical numbers of entries.\n\n- mailmap maps email addresses to full names, for display purposes only.\nTypically a long list.\n\n- git svn's author file maps usernames to fullname . But for\nevery svn repo I need a file following their chosen keys (usernames),\nrather than abbreviations I would remember.\n\n- alias files for send-email map keys to fullname . That indeed\nis a mapping and a purpose similar to my intention for git commit\n--author. Problem here is that it's in perl and supports various\ndifferent formats.\n\nI think for send-email you would typically use your mua's alias file.\n\nFor git commit --author abbreviations at least I would typically need\nonly very few entries (be it per repo or globally), which means they can\nbe much shorter (than my mua aliases) in order to be unique, and I don't\nreally want an extra file for that.\n\nSo, while in fact I wouldn't have been able to implement it differently\nanyways, there are other good reasons as well. :)\n\n>> --- In an ideal word, all my collaborators would exchange changes\n>> as git patches (or even via pull/push). In the real world, they\n>> send new versions which I integrate (after dealing with their\n>> whitespace and encoding changes...). Therefore, being able to say \n>> \"git commit --author=mickey\" and having git translate \"mickey\" into\n>> \"Mickey Mouse \" is a real time saver. The patch\n>> accomplishes this by reading config keys \"user.mickey.name\" and\n>> \"user.mickey.email\" when encountering an --author argument without\n>> \"<>\".\n> \n> This justification should probably go into the commit message, not\n> the cover letter. When you are writing it, think about the reader who\n> will bisect or blame to your commit a year from now. Will they want\n> to see just _what_ you did, or _why_ you did it?\n\nOK. I think I'm still thinking in terms of \"change log style\" commit\nmessages. I haven't completely switched from svn to git yet, neither\ntechnically nor intellectually, it seems. Read \"brain rotten\" ;)\n\n>> If there's interest in this patch I'll follow up with a\n>> documentation patch.\n> \n> I think Miklos already yelled at you for this. The message he\n> referenced doesn't quite apply, because you did include some\n> discussion of the \"why\".\n\nHe didn't mean to yell, we corresponded off-list, all is well.\n\n[snip]\n\n> final patch\" then that would have gone over very well. But as it \n> happens, you chose the magic pet peeve words. ;)\n\nNewcomer's luck, I'm fine with that.\n\n> \n>> The \"--committer\" argument to git commit is not treated because I\n>> don't consider it worthwhile.\n\nI managed to fool everyone, including myself. There is no --committer\noption. I feel in good company now ;)\n\nThere is GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL, and likewise for\nauthor. My patch does not use any of these, it only deals with (the)\noption argument(s). Explicitely set *_{NAME,EMAIL} should be respected\nas is.\n\n> If you are introducing a new source of alias mappings, it would make \n> sense to me to support it everywhere for the sake of consistency.\n> That means --committer should look at it, too (and should only be a\n> few lines, I would think), and probably git-send-email.\n>> P.S.: That's my first patch here. Yes, I've read\n>> Doc/SubmittingPatches. So, if something's wrong, please be gentle\n>> but not overly so ;)\n> \n> I hope this is the right amount of gentleness. ;)\n> \n>> --- a/builtin-commit.c +++ b/builtin-commit.c @@ -53,6 +53,12 @@\n>> static char *author_name, *author_email, *author_date; static int\n>> all, edit_flag, also, interactive, only, amend, signoff; static int\n>> quiet, verbose, no_verify, allow_empty; static char\n>> *untracked_files_arg; +struct user { +\tchar *name, *full_name,\n>> *email; +};\n> \n> Others may disagree, but style-wise I think we usually put each\n> struct member on its own line.\n> \n>> if (force_author) { const char *lb = strstr(force_author, \" <\"); \n>> const char *rb = strchr(force_author, '>');\n>> \n>> +\t\tif (!lb && !rb) { +\t\t\tfor (i=0; i < users_nr; i++) {\n> \n> Style: \"i = 0\"\n> \n>> +\t\t\t\tif (!strcmp(force_author, users[i]->name)) { +\t\t\t\t\tauthor_name\n>> = users[i]->full_name; +\t\t\t\t\tauthor_email = users[i]->email; +\n>> return; +\t\t\t\t}\n> \n> \n> I haven't traced all of the uses of author_name and author_email, but\n> all of the other codepaths seem to allocate a new string, whereas\n\n..because they need to make a local (for the function) string global\n(for the file)...\n\n> this uses the existing strings.\n\n...because they are (file) global already.\n\n> Is this going to accidentally free()\n> from the users list, or are we just leaking those other strings now?\n\nSame as branches in remote.c, see below. They're not freed accidentally\nin builtin-commit.c\n\n> \n>> +\tALLOC_GROW(users, users_nr + 1, users_alloc);\n> \n> Yay, a first-time submitter bothered to use ALLOC_GROW! :)\n> \n>> +\tret = xcalloc(1, sizeof(struct user)); +\tusers[users_nr++] = ret;\n>> +\tif (len) +\t\tret->name = xstrndup(name, len); +\telse +\t\tret->name\n>> = xstrdup(name); + +\treturn ret; +}\n> \n> This is the not the most git-ish way of using the config[1]. Usually\n> we avoid reading big lists into memory, but rather just call\n> git_config with the appropriate callback when we find we need to look\n> up the user alias.\n> \n> [1] However, I don't necessarily agree with this. We can end up\n> parsing the config (which may be split across 3 files) several times\n> per command, so it is probably better to just parse and store it in\n> one go. So I will let Junio comment on the preferred method.\n\nI was looking all over the existing code for a function which would do\nwhat \"git config --get $key\" does, and didn't find any. I ended up\ncopying the logic (and code) from remote.c's parsing of \"branch.*.*\".\n[Should I have attributed this somehow? ]\n\nI understand there are good reasons for this (the way the config is\nparsed): a generic central config parser wouldn't be able to verify the\nentries when reading the config.\nOTOH, verifying an entry when using it wouldn't be that much later. So,\nreading the complete config once and storing it in a global struct\nshould be an alternative which would provide a central place for all\nparsing. Judging the implications is way above my current understanding\nof the codebase, not to mention implementing it.\n\nCheers\nMichael\n\nP.S.: I should have split this up. Next post will be shorter.\n"},{"id":"88158","messageId":"20080822165047.GA3339@sigill.intra.peff.net","threadId":"15126","inReplyTo":"48AE786C.20201@fastmail.fm","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-22T16:50:48Z","receivedAt":"2008-08-22T16:50:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[oops, this accidentally got taken off the list, so here is a repost to\nthe list and all interested parties]\n\nOn Fri, Aug 22, 2008 at 10:27:24AM +0200, Michael J Gruber wrote:\n\n> There's also git svn.\n> I think all of these serve different purposes, and have different\n> typical numbers of entries.\n> \n> - mailmap maps email addresses to full names, for display purposes only.\n> Typically a long list.\n> \n> - git svn's author file maps usernames to fullname . But for\n> every svn repo I need a file following their chosen keys (usernames),\n> rather than abbreviations I would remember.\n> \n> - alias files for send-email map keys to fullname . That indeed\n> is a mapping and a purpose similar to my intention for git commit\n> --author. Problem here is that it's in perl and supports various\n> different formats.\n\nI agree with your analysis here. The mapping done by mailmap and git-svn\naren't the same. The ones for send-email are, but there is simply an\nimplementation hurdle.\n\n> I think for send-email you would typically use your mua's alias file.\n> \n> For git commit --author abbreviations at least I would typically need\n> only very few entries (be it per repo or globally), which means they can\n> be much shorter (than my mua aliases) in order to be unique, and I don't\n> really want an extra file for that.\n\nI think this depends on your situation. In your case, it sounds like you\nwant to configure a few names that frequently have --author fields for\nyour specific workflow. For me, even though only 1% of the people in my\nmua's alias file might send me patches, 99% of the people I would want\nto use --author on are in my mua's alias file.\n\nSo while there are may only be a few needed entries, they are already\nthere for me. Of course, I don't really use --author much, since most\npeople I talk to are already git users. ;) So I am extrapolating a bit.\n\n> >> The \"--committer\" argument to git commit is not treated because I\n> >> don't consider it worthwhile.\n> \n> I managed to fool everyone, including myself. There is no --committer\n> option. I feel in good company now ;)\n\nHeh.\n\n> There is GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL, and likewise for\n> author. My patch does not use any of these, it only deals with (the)\n> option argument(s). Explicitely set *_{NAME,EMAIL} should be respected\n> as is.\n\nI think that is sensible.\n\n> > I haven't traced all of the uses of author_name and author_email, but\n> > all of the other codepaths seem to allocate a new string, whereas\n> \n> ..because they need to make a local (for the function) string global\n> (for the file)...\n> \n> > this uses the existing strings.\n> \n> ...because they are (file) global already.\n> \n> > Is this going to accidentally free()\n> > from the users list, or are we just leaking those other strings now?\n> \n> Same as branches in remote.c, see below. They're not freed accidentally\n> in builtin-commit.c\n\nOK, I see. I wonder if it is worth xstrdup'ing them _anyway_, so that\ndetermine_author_info produces a consistent result, and the person who\nlater does the free() cleanup won't get a nasty surprise. But the\nleakage is probably not enough to really care about in this instance.\n\n> I was looking all over the existing code for a function which would do\n> what \"git config --get $key\" does, and didn't find any. I ended up\n> copying the logic (and code) from remote.c's parsing of \"branch.*.*\".\n> [Should I have attributed this somehow? ]\n\nNo, no need to attribute in this case, I think.\n\nI think the way you have done the config is fine, unless somebody else\nhas a major style objection (and yes, there are examples of similar\nstyles).\n\n-Peff\n"},{"id":"88197","messageId":"7vzln492pc.fsf@gitster.siamese.dyndns.org","threadId":"15126","inReplyTo":"20080822165047.GA3339@sigill.intra.peff.net","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-22T21:09:35Z","receivedAt":"2008-08-22T21:09:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> For git commit --author abbreviations at least I would typically need\n>> only very few entries (be it per repo or globally), which means they can\n>> be much shorter (than my mua aliases) in order to be unique, and I don't\n>> really want an extra file for that.\n>\n> I think this depends on your situation. In your case, it sounds like you\n> want to configure a few names that frequently have --author fields for\n> your specific workflow. For me, even though only 1% of the people in my\n> mua's alias file might send me patches, 99% of the people I would want\n> to use --author on are in my mua's alias file.\n>\n> So while there are may only be a few needed entries, they are already\n> there for me. Of course, I don't really use --author much, since most\n> people I talk to are already git users. ;) So I am extrapolating a bit.\n\nAnother potential source of this information is the existing commits. If\nyou are communicating with the same set of people already, you already\nhave the information in your repository. I suspect Michael's \"selected\nfew co-workers that would comfortably fit in a small list of config\nentries without need for any external text file\" use case would be better\nserved by an approach to look into existing commits.\n\nI often use \"git who Jeff\" alias to fill the recipient of my e-mails with\nthis alias:\n\n [alias]\n who = \"!sh -c 'git log -1 --pretty=\\\"format:%an <%ae>\\\" --author=\\\"$1\\\"' -\"\n one = \"!sh -c 'git show -s --pretty=\\\"format:%h (%s, %ai\\\" \\\"$@\\\" | sed -e \\\"s/ [012][0-9]:[0-5][0-9]:[0-5][0-9] [-+][0-9][0-9][0-9][0-9]$/)/\\\"' -\"\n"},{"id":"88204","messageId":"20080822211902.GA31884@coredump.intra.peff.net","threadId":"15126","inReplyTo":"7vzln492pc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-22T21:19:02Z","receivedAt":"2008-08-22T21:19:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 22, 2008 at 02:09:35PM -0700, Junio C Hamano wrote:\n\n> I often use \"git who Jeff\" alias to fill the recipient of my e-mails with\n> this alias:\n> \n> [alias]\n> who = \"!sh -c 'git log -1 --pretty=\\\"format:%an <%ae>\\\" --author=\\\"$1\\\"' -\"\n\nVery clever, I like it. And it also solves the problem I sometimes _do_\nhave, which is pulling aliases into my mua from git.\n\n-Peff\n"},{"id":"88356","messageId":"8F4F767F-3D7B-4358-AAD3-8E2BC7EA108D@simplicidade.org","threadId":"15126","inReplyTo":"7vzln492pc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Pedro Melo","fromEmail":"melo@simplicidade.org","sentAt":"2008-08-24T09:19:20Z","receivedAt":"2008-08-24T09:19:20Z","isPatch":true,"sender":{"key":"melo@simplicidade.org","avatar":"https://gravatar.com/avatar/13ddbb01e300285a93aa1e3739653a81f9b1d3438bd03a4ac36b88e4ffeeafc3?d=mp&s=160"},"body":"Hi,\n\nOn Aug 22, 2008, at 10:09 PM, Junio C Hamano wrote:\n> Another potential source of this information is the existing \n> commits. If\n> you are communicating with the same set of people already, you already\n> have the information in your repository. I suspect Michael's \n> \"selected\n> few co-workers that would comfortably fit in a small list of config\n> entries without need for any external text file\" use case would be \n> better\n> served by an approach to look into existing commits.\n>\n> I often use \"git who Jeff\" alias to fill the recipient of my e- \n> mails with\n> this alias:\n>\n> [alias]\n> who = \"!sh -c 'git log -1 --pretty=\\\"format:%an <%ae>\\\" -- \n> author=\\\"$1\\\"' -\"\n\nNice:)\n\n> one = \"!sh -c 'git show -s --pretty=\\\"format:%h (%s, %ai\\\" \n> \\\"$@\\\" | sed -e \\\"s/ [012][0-9]:[0-5][0-9]:[0-5][0-9] [-+][0-9][0-9] \n> [0-9][0-9]$/)/\\\"' -\"\n\nCan you explain this one? It seems a bit like git describe, but it \nmisses a single char at the beggining?\n\ngit (master) $ git one\n2ebc02d (Start 1.6.1 cycle, 2008-08-17)\n\ngit (master) $ git describe\nv1.6.0-2-g2ebc02d\n\nBest regards,\n-- \nPedro Melo\nBlog: http://www.simplicidade.org/notes/\nXMPP ID: melo@simplicidade.org\nUse XMPP!\n"},{"id":"88366","messageId":"20080824172145.GA25553@coredump.intra.peff.net","threadId":"15126","inReplyTo":"8F4F767F-3D7B-4358-AAD3-8E2BC7EA108D@simplicidade.org","subject":"Re: [PATCH] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-24T17:21:46Z","receivedAt":"2008-08-24T17:21:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 24, 2008 at 10:19:20AM +0100, Pedro Melo wrote:\n\n>> one = \"!sh -c 'git show -s --pretty=\\\"format:%h (%s, %ai\\\" \n>> \\\"$@\\\" | sed -e \\\"s/ [012][0-9]:[0-5][0-9]:[0-5][0-9] [-+][0-9][0-9] \n>> [0-9][0-9]$/)/\\\"' -\"\n>\n> Can you explain this one? It seems a bit like git describe, but it misses \n> a single char at the beggining?\n>\n> git (master) $ git one\n> 2ebc02d (Start 1.6.1 cycle, 2008-08-17)\n>\n> git (master) $ git describe\n> v1.6.0-2-g2ebc02d\n\nThe 'g' character is not part of the sha1, but just a prefix used by git\ndescribe. The point of this alias is to refer (in email or other\nwriting) to commits. Obviously just the sha1 would be sufficient, but\nthe subject and date of the commit gives the reader some context without\nthem having to plug it into git-show.\n\n-Peff\n"},{"id":"88414","messageId":"20080825013837.GA17201@coredump.intra.peff.net","threadId":"15126","inReplyTo":"7vzln492pc.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] fix \"git log -i --grep\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-25T01:38:37Z","receivedAt":"2008-08-25T01:38:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 22, 2008 at 02:09:35PM -0700, Junio C Hamano wrote:\n\n> [alias]\n> who = \"!sh -c 'git log -1 --pretty=\\\"format:%an <%ae>\\\" --author=\\\"$1\\\"' -\"\n\nI have two improvements for this, and one of them caused me to find a\ngit bug, for which the fix is below. :)\n\n 1. I tried this with --no-pager, which made it obvious that this\n should be using --pretty=tformat to append a newline.\n\n 2. I use it with \"-i\" so I don't have to hit the shift key. And that's\n what revealed the bug.\n\n-- >8 --\nfix \"git log -i --grep\"\n\nThis has been broken in v1.6.0 due to the reorganization of\nthe revision option parsing code. The \"-i\" is completely\nignored, but works fine in \"git log --grep -i\".\n\nWhat happens is that the code for \"-i\" looks for\nrevs->grep_filter; if it is NULL, we do nothing, since there\nare no grep filters. But that is obviously not correct,\nsince we want it to influence the later --grep option. Doing\nit the other way around works, since \"-i\" just impacts the\nexisting grep_filter option.\n\nThe fix is to allocate the grep_filter member whenever we\nget _any_ grep information, be it actual filters or just\nflags. Thus checking for non-NULL revs->grep_filter is no\nlonger sufficient to know that we have patterns; in\ncommit_match we must actually check that the pattern list is\nnot empty.\n\nSigned-off-by: Jeff King \n---\nI didn't bother bisecting, but I'm pretty sure this was a fallout from\nPierre's revision option parsing rewrite.\n\nThis was generated with -U5 to make the first hunk easier to read.\n\nWe could potentially make revs->grep_filter a part of the struct, rather\nthan malloc'ing it (since we have to look inside grep_filter anyway to\nsee if there are any patterns). But that still doesn't save us from a\nsetup_grep call, since we have to initialize some values inside it.\nPotentially this setup (which is not very costly) could just be done\nwhen initializing the rev_info struct, and then we could just assume\nthat grep_filter was always valid.\n\nI went with the less intrusive change in this case, but I am happy to\nwork it up the other way.\n\n revision.c | 25 +++++++++++++++----------\n t/t4202-log.sh | 22 ++++++++++++++++++++++\n 2 files changed, 37 insertions(+), 10 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 8cd39da..a73612f 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -942,19 +942,24 @@ void read_revisions_from_stdin(struct rev_info *revs)\n \t\tif (handle_revision_arg(line, revs, 0, 1))\n \t\t\tdie(\"bad revision '%s'\", line);\n \t}\n }\n \n-static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)\n+static void setup_grep(struct rev_info *revs)\n {\n \tif (!revs->grep_filter) {\n \t\tstruct grep_opt *opt = xcalloc(1, sizeof(*opt));\n \t\topt->status_only = 1;\n \t\topt->pattern_tail = &(opt->pattern_list);\n \t\topt->regflags = REG_NEWLINE;\n \t\trevs->grep_filter = opt;\n \t}\n+}\n+\n+static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)\n+{\n+\tsetup_grep(revs);\n \tappend_grep_pattern(revs->grep_filter, ptn,\n \t\t\t \"command line\", 0, what);\n }\n \n static void add_header_grep(struct rev_info *revs, const char *field, const char *pattern)\n@@ -1167,21 +1172,21 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t} else if (!prefixcmp(arg, \"--committer=\")) {\n \t\tadd_header_grep(revs, \"committer\", arg+12);\n \t} else if (!prefixcmp(arg, \"--grep=\")) {\n \t\tadd_message_grep(revs, arg+7);\n \t} else if (!strcmp(arg, \"--extended-regexp\") || !strcmp(arg, \"-E\")) {\n-\t\tif (revs->grep_filter)\n-\t\t\trevs->grep_filter->regflags |= REG_EXTENDED;\n+\t\tsetup_grep(revs);\n+\t\trevs->grep_filter->regflags |= REG_EXTENDED;\n \t} else if (!strcmp(arg, \"--regexp-ignore-case\") || !strcmp(arg, \"-i\")) {\n-\t\tif (revs->grep_filter)\n-\t\t\trevs->grep_filter->regflags |= REG_ICASE;\n+\t\tsetup_grep(revs);\n+\t\trevs->grep_filter->regflags |= REG_ICASE;\n \t} else if (!strcmp(arg, \"--fixed-strings\") || !strcmp(arg, \"-F\")) {\n-\t\tif (revs->grep_filter)\n-\t\t\trevs->grep_filter->fixed = 1;\n+\t\tsetup_grep(revs);\n+\t\trevs->grep_filter->fixed = 1;\n \t} else if (!strcmp(arg, \"--all-match\")) {\n-\t\tif (revs->grep_filter)\n-\t\t\trevs->grep_filter->all_match = 1;\n+\t\tsetup_grep(revs);\n+\t\trevs->grep_filter->all_match = 1;\n \t} else if (!prefixcmp(arg, \"--encoding=\")) {\n \t\targ += 11;\n \t\tif (strcmp(arg, \"none\"))\n \t\t\tgit_log_output_encoding = xstrdup(arg);\n \t\telse\n@@ -1647,11 +1652,11 @@ static int rewrite_parents(struct rev_info *revs, struct commit *commit)\n \treturn 0;\n }\n \n static int commit_match(struct commit *commit, struct rev_info *opt)\n {\n-\tif (!opt->grep_filter)\n+\tif (!opt->grep_filter || !opt->grep_filter->pattern_list)\n \t\treturn 1;\n \treturn grep_buffer(opt->grep_filter,\n \t\t\t NULL, /* we say nothing, not even filename */\n \t\t\t commit->buffer, strlen(commit->buffer));\n }\ndiff --git a/t/t4202-log.sh b/t/t4202-log.sh\nindex 4c8af45..0ab925c 100755\n--- a/t/t4202-log.sh\n+++ b/t/t4202-log.sh\n@@ -67,9 +67,31 @@ test_expect_success 'diff-filter=D' '\n \t\tfalse\n \t}\n \n '\n \n+test_expect_success 'setup case sensitivity tests' '\n+\techo case >one &&\n+\ttest_tick &&\n+\tgit commit -a -m Second\n+'\n+\n+test_expect_success 'log --grep' '\n+\techo second >expect &&\n+\tgit log -1 --pretty=\"tformat:%s\" --grep=sec >actual &&\n+\ttest_cmp expect actual\n+'\n \n+test_expect_success 'log -i --grep' '\n+\techo Second >expect &&\n+\tgit log -1 --pretty=\"tformat:%s\" -i --grep=sec >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'log --grep -i' '\n+\techo Second >expect &&\n+\tgit log -1 --pretty=\"tformat:%s\" --grep=sec -i >actual &&\n+\ttest_cmp expect actual\n+'\n \n test_done\n \n-- \n1.6.0.150.gc3242.dirty\n"},{"id":"88419","messageId":"20080825021029.GA28355@coredump.intra.peff.net","threadId":"15126","inReplyTo":"20080825013837.GA17201@coredump.intra.peff.net","subject":"[PATCH] format-patch: use default diff format even with patch options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-25T02:10:29Z","receivedAt":"2008-08-25T02:10:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 24, 2008 at 09:38:37PM -0400, Jeff King wrote:\n\n> This was generated with -U5 to make the first hunk easier to read.\n\nAnd while doing that, I detected another bug. Or maybe a feature,\ndepending on your perspective.\n\n-- >8 --\nformat-patch: use default diff format even with patch options\n\nPreviously, running \"git format-patch -U5\" would cause the\nlow-level diff machinery to change the diff output format\nfrom \"not specified\" to \"patch\". This meant that\nformat-patch thought we explicitly specified a diff output\nformat, and would not use the default format. The resulting\nmessage lacked both the diffstat and the summary, as well as\nthe separating \"---\".\n\nNow format-patch explicitly checks for this condition and\nuses the default. That means that \"git format-patch -p\" will\nnow have the \"-p\" ignored.\n\nSigned-off-by: Jeff King \n---\nMaybe this is intentional, and that by asking for \"-U\" I am explicitly\nsaying \"I really want the patch format, not the default.\" But I think\nthis more reasonably maps to what the user expects.\n\nI am a little uncomfortable hurting anyone who thought that\n\"format-patch -p\" was a good idea. OTOH:\n\n 1. I have to question why they were using format-patch in the first\n place. Probably git-log --pretty=email would be a better fit.\n\n 2. Their mails were already broken, since the presence of the diffstat\n is what triggers the \"---\" divider.\n\n builtin-log.c | 3 ++-\n t/t4014-format-patch.sh | 25 +++++++++++++++++++++++++\n 2 files changed, 27 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 9204ffd..1d3c5cb 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -932,7 +932,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \tif (argc > 1)\n \t\tdie (\"unrecognized argument: %s\", argv[1]);\n \n-\tif (!rev.diffopt.output_format)\n+\tif (!rev.diffopt.output_format\n+\t\t|| rev.diffopt.output_format == DIFF_FORMAT_PATCH)\n \t\trev.diffopt.output_format = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_SUMMARY | DIFF_FORMAT_PATCH;\n \n \tif (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)\ndiff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh\nindex 7fe853c..9d99dc2 100755\n--- a/t/t4014-format-patch.sh\n+++ b/t/t4014-format-patch.sh\n@@ -230,4 +230,29 @@ test_expect_success 'shortlog of cover-letter wraps overly-long onelines' '\n \n '\n \n+cat > expect << EOF\n+---\n+ file | 16 ++++++++++++++++\n+ 1 files changed, 16 insertions(+), 0 deletions(-)\n+\n+diff --git a/file b/file\n+index 40f36c6..2dc5c23 100644\n+--- a/file\n++++ b/file\n+@@ -13,4 +13,20 @@ C\n+ 10\n+ D\n+ E\n+ F\n++5\n+EOF\n+\n+test_expect_success 'format-patch respects -U' '\n+\n+\tgit format-patch -U4 -2 &&\n+\tsed -e \"1,/^$/d\" -e \"/^+5/q\" < 0001-This-is-an-excessively-long-subject-line-for-a-messa.patch > output &&\n+\ttest_cmp expect output\n+\n+'\n+\n test_done\n-- \n1.6.0.150.gc3242.dirty\n"},{"id":"88426","messageId":"7vr68ditd8.fsf@gitster.siamese.dyndns.org","threadId":"15126","inReplyTo":"20080825021029.GA28355@coredump.intra.peff.net","subject":"Re: [PATCH] format-patch: use default diff format even with patch options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-25T04:57:55Z","receivedAt":"2008-08-25T04:57:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I am a little uncomfortable hurting anyone who thought that\n> \"format-patch -p\" was a good idea. OTOH:\n>\n> 1. I have to question why they were using format-patch in the first\n> place. Probably git-log --pretty=email would be a better fit.\n>\n> 2. Their mails were already broken, since the presence of the diffstat\n> is what triggers the \"---\" divider.\n>\n> builtin-log.c | 3 ++-\n> t/t4014-format-patch.sh | 25 +++++++++++++++++++++++++\n> 2 files changed, 27 insertions(+), 1 deletions(-)\n>\n> diff --git a/builtin-log.c b/builtin-log.c\n> index 9204ffd..1d3c5cb 100644\n> --- a/builtin-log.c\n> +++ b/builtin-log.c\n> @@ -932,7 +932,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n> \tif (argc > 1)\n> \t\tdie (\"unrecognized argument: %s\", argv[1]);\n> \n> -\tif (!rev.diffopt.output_format)\n> +\tif (!rev.diffopt.output_format\n> +\t\t|| rev.diffopt.output_format == DIFF_FORMAT_PATCH)\n> \t\trev.diffopt.output_format = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_SUMMARY | DIFF_FORMAT_PATCH;\n> \n> \tif (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)\n\nI think this is the right thing to do. The only unusual option somebody\nmight want to use would be \"format-patch --stat $range\" to send out commit\nlog e-mails with diffstat summary but without the actual patch, but your\nchange does not break that use case either.\n"},{"id":"88428","messageId":"7vmyj1isot.fsf@gitster.siamese.dyndns.org","threadId":"15126","inReplyTo":"20080825013837.GA17201@coredump.intra.peff.net","subject":"Re: [PATCH] fix \"git log -i --grep\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-25T05:12:34Z","receivedAt":"2008-08-25T05:12:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Aug 22, 2008 at 02:09:35PM -0700, Junio C Hamano wrote:\n>\n>> [alias]\n>> who = \"!sh -c 'git log -1 --pretty=\\\"format:%an <%ae>\\\" --author=\\\"$1\\\"' -\"\n>\n> I have two improvements for this, and one of them caused me to find a\n> git bug, for which the fix is below. :)\n>\n> 1. I tried this with --no-pager, which made it obvious that this\n> should be using --pretty=tformat to append a newline.\n\nStrict reading of POSIX suggests that you are not supposed to send an\ninput that has incomplete line to \"sed\", so tformat may be the right thing\nto use for that reason as well.\n\nHowever.\n\nMy sed is non POSIX in a good sense and does not have problem handing such\nan input, and my use case is to say \"\\C-u \\M-! git who Jeff \" while\ntyping e-mail message, and I do _not_ want an extra newline after the\ninput. That is why I use format: (not tformat:) there.\n\n> The fix is to allocate the grep_filter member whenever we\n> get _any_ grep information, be it actual filters or just\n> flags. Thus checking for non-NULL revs->grep_filter is no\n> longer sufficient to know that we have patterns; in\n> commit_match we must actually check that the pattern list is\n> not empty.\n\nWell spotted, and thanks for the fix.\n\nAs you suggested, making the grep option structure embedded in rev_info\nmay not be a bad idea. We used to keep track of the sub-options\nseparately while we encounter, and updated grep_filter at the end of the\nloop, but the conversion to use parse-options broke it.\n\nThe only issue I still have, which I suspect your fix has made it easier\nto address, is to complain if sub-options to grep like -i and -E are given\nwithout --grep. That's not something v1.5.6 series did, though.\n"},{"id":"88433","messageId":"20080825061504.GA9313@coredump.intra.peff.net","threadId":"15126","inReplyTo":"7vmyj1isot.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] fix \"git log -i --grep\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-25T06:15:05Z","receivedAt":"2008-08-25T06:15:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 24, 2008 at 10:12:34PM -0700, Junio C Hamano wrote:\n\n> My sed is non POSIX in a good sense and does not have problem handing such\n> an input, and my use case is to say \"\\C-u \\M-! git who Jeff \" while\n> typing e-mail message, and I do _not_ want an extra newline after the\n> input. That is why I use format: (not tformat:) there.\n\nAh. I would have expected whatever you pulled the output into to eat the\nnewline. But there is no point in nitpicking, as this is a personal\nalias. Mine uses tformat. :)\n\n> > The fix is to allocate the grep_filter member whenever we\n> > get _any_ grep information, be it actual filters or just\n> > flags. Thus checking for non-NULL revs->grep_filter is no\n> > longer sufficient to know that we have patterns; in\n> > commit_match we must actually check that the pattern list is\n> > not empty.\n> \n> Well spotted, and thanks for the fix.\n\nActually, there is one spot missing from my previous patch. Rev-list\nsets \"save_commit_buffer\" based on the value of grep_filter. So it must\nalso check grep_filter->pattern_list.\n\n> As you suggested, making the grep option structure embedded in rev_info\n> may not be a bad idea. We used to keep track of the sub-options\n> separately while we encounter, and updated grep_filter at the end of the\n> loop, but the conversion to use parse-options broke it.\n\nI worked up this patch, and it is below. However, I think it may not be\na good idea, because...\n\n> The only issue I still have, which I suspect your fix has made it easier\n> to address, is to complain if sub-options to grep like -i and -E are given\n> without --grep. That's not something v1.5.6 series did, though.\n\nThis is trivial with my first patch, but not with the second. With\ngrep_filter kept as a pointer, we know that if the pointer is non-NULL\nbut there are no patterns, then the user asked for grep options but\nnever --grep.\n\nI guess this might be a helpful thing for some users, but I wonder if it\nis being too unpredictable for script usage. I.e., a script like:\n\n git log -E `for i in \"$@\"; do echo --author=$i`\n\nAnyway, the non-allocating patch is below. Aside from the test case, it\ndeletes more lines than it adds, which is always nice.\n\n-- >8 --\nfix \"git log -i --grep\"\n\nThis has been broken in v1.6.0 due to the reorganization of\nthe revision option parsing code. The \"-i\" is completely\nignored, but works fine in \"git log --grep -i\".\n\nWhat happens is that the code for \"-i\" looks for\nrevs->grep_filter; if it is NULL, we do nothing, since there\nare no grep filters. But that is obviously not correct,\nsince we want it to influence the later --grep option. Doing\nit the other way around works, since \"-i\" just impacts the\nexisting grep_filter option.\n\nInstead, we now always initialize the grep_filter member and\njust fill in options and patterns as we get them. This means\nthat we can no longer check grep_filter for NULL, but\ninstead must check the pattern list to see if we have any\nactual patterns.\n\nSigned-off-by: Jeff King \n---\n builtin-rev-list.c | 3 ++-\n revision.c | 34 ++++++++++++----------------------\n revision.h | 3 ++-\n t/t4202-log.sh | 22 ++++++++++++++++++++++\n 4 files changed, 38 insertions(+), 24 deletions(-)\n\ndiff --git a/builtin-rev-list.c b/builtin-rev-list.c\nindex 893762c..c023003 100644\n--- a/builtin-rev-list.c\n+++ b/builtin-rev-list.c\n@@ -645,7 +645,8 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)\n \t revs.diff)\n \t\tusage(rev_list_usage);\n \n-\tsave_commit_buffer = revs.verbose_header || revs.grep_filter;\n+\tsave_commit_buffer = revs.verbose_header ||\n+\t\trevs.grep_filter.pattern_list;\n \tif (bisect_list)\n \t\trevs.limited = 1;\n \ndiff --git a/revision.c b/revision.c\nindex e75079a..36291b6 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -782,6 +782,10 @@ void init_revisions(struct rev_info *revs, const char *prefix)\n \n \trevs->commit_format = CMIT_FMT_DEFAULT;\n \n+\trevs->grep_filter.status_only = 1;\n+\trevs->grep_filter.pattern_tail = &(revs->grep_filter.pattern_list);\n+\trevs->grep_filter.regflags = REG_NEWLINE;\n+\n \tdiff_setup(&revs->diffopt);\n \tif (prefix && !revs->diffopt.prefix) {\n \t\trevs->diffopt.prefix = prefix;\n@@ -946,15 +950,7 @@ void read_revisions_from_stdin(struct rev_info *revs)\n \n static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)\n {\n-\tif (!revs->grep_filter) {\n-\t\tstruct grep_opt *opt = xcalloc(1, sizeof(*opt));\n-\t\topt->status_only = 1;\n-\t\topt->pattern_tail = &(opt->pattern_list);\n-\t\topt->regflags = REG_NEWLINE;\n-\t\trevs->grep_filter = opt;\n-\t}\n-\tappend_grep_pattern(revs->grep_filter, ptn,\n-\t\t\t \"command line\", 0, what);\n+\tappend_grep_pattern(&revs->grep_filter, ptn, \"command line\", 0, what);\n }\n \n static void add_header_grep(struct rev_info *revs, const char *field, const char *pattern)\n@@ -1164,17 +1160,13 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t} else if (!prefixcmp(arg, \"--grep=\")) {\n \t\tadd_message_grep(revs, arg+7);\n \t} else if (!strcmp(arg, \"--extended-regexp\") || !strcmp(arg, \"-E\")) {\n-\t\tif (revs->grep_filter)\n-\t\t\trevs->grep_filter->regflags |= REG_EXTENDED;\n+\t\trevs->grep_filter.regflags |= REG_EXTENDED;\n \t} else if (!strcmp(arg, \"--regexp-ignore-case\") || !strcmp(arg, \"-i\")) {\n-\t\tif (revs->grep_filter)\n-\t\t\trevs->grep_filter->regflags |= REG_ICASE;\n+\t\trevs->grep_filter.regflags |= REG_ICASE;\n \t} else if (!strcmp(arg, \"--fixed-strings\") || !strcmp(arg, \"-F\")) {\n-\t\tif (revs->grep_filter)\n-\t\t\trevs->grep_filter->fixed = 1;\n+\t\trevs->grep_filter.fixed = 1;\n \t} else if (!strcmp(arg, \"--all-match\")) {\n-\t\tif (revs->grep_filter)\n-\t\t\trevs->grep_filter->all_match = 1;\n+\t\trevs->grep_filter.all_match = 1;\n \t} else if (!prefixcmp(arg, \"--encoding=\")) {\n \t\targ += 11;\n \t\tif (strcmp(arg, \"none\"))\n@@ -1349,9 +1341,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \tif (diff_setup_done(&revs->diffopt) < 0)\n \t\tdie(\"diff_setup_done failed\");\n \n-\tif (revs->grep_filter) {\n-\t\tcompile_grep_patterns(revs->grep_filter);\n-\t}\n+\tcompile_grep_patterns(&revs->grep_filter);\n \n \tif (revs->reverse && revs->reflog_info)\n \t\tdie(\"cannot combine --reverse with --walk-reflogs\");\n@@ -1492,9 +1482,9 @@ static int rewrite_parents(struct rev_info *revs, struct commit *commit)\n \n static int commit_match(struct commit *commit, struct rev_info *opt)\n {\n-\tif (!opt->grep_filter)\n+\tif (!opt->grep_filter.pattern_list)\n \t\treturn 1;\n-\treturn grep_buffer(opt->grep_filter,\n+\treturn grep_buffer(&opt->grep_filter,\n \t\t\t NULL, /* we say nothing, not even filename */\n \t\t\t commit->buffer, strlen(commit->buffer));\n }\ndiff --git a/revision.h b/revision.h\nindex 1b04566..91f1944 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -2,6 +2,7 @@\n #define REVISION_H\n \n #include \"parse-options.h\"\n+#include \"grep.h\"\n \n #define SEEN\t\t(1u<<0)\n #define UNINTERESTING (1u<<1)\n@@ -92,7 +93,7 @@ struct rev_info {\n \tint\t\tshow_log_size;\n \n \t/* Filter by commit log message */\n-\tstruct grep_opt\t*grep_filter;\n+\tstruct grep_opt\tgrep_filter;\n \n \t/* Display history graph */\n \tstruct git_graph *graph;\ndiff --git a/t/t4202-log.sh b/t/t4202-log.sh\nindex 4c8af45..0ab925c 100755\n--- a/t/t4202-log.sh\n+++ b/t/t4202-log.sh\n@@ -69,7 +69,29 @@ test_expect_success 'diff-filter=D' '\n \n '\n \n+test_expect_success 'setup case sensitivity tests' '\n+\techo case >one &&\n+\ttest_tick &&\n+\tgit commit -a -m Second\n+'\n+\n+test_expect_success 'log --grep' '\n+\techo second >expect &&\n+\tgit log -1 --pretty=\"tformat:%s\" --grep=sec >actual &&\n+\ttest_cmp expect actual\n+'\n \n+test_expect_success 'log -i --grep' '\n+\techo Second >expect &&\n+\tgit log -1 --pretty=\"tformat:%s\" -i --grep=sec >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'log --grep -i' '\n+\techo Second >expect &&\n+\tgit log -1 --pretty=\"tformat:%s\" --grep=sec -i >actual &&\n+\ttest_cmp expect actual\n+'\n \n test_done\n \n-- \n1.6.0.150.gc3242.dirty\n"},{"id":"88434","messageId":"20080825061833.GB9313@coredump.intra.peff.net","threadId":"15126","inReplyTo":"20080825061504.GA9313@coredump.intra.peff.net","subject":"Re: [PATCH] fix \"git log -i --grep\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-25T06:18:33Z","receivedAt":"2008-08-25T06:18:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 25, 2008 at 02:15:05AM -0400, Jeff King wrote:\n\n> > As you suggested, making the grep option structure embedded in rev_info\n> > may not be a bad idea. We used to keep track of the sub-options\n> > separately while we encounter, and updated grep_filter at the end of the\n> > loop, but the conversion to use parse-options broke it.\n> \n> I worked up this patch, and it is below. However, I think it may not be\n> a good idea, because...\n\nActually, let me amend that. While writing the email, I came to the\nconclusion that the \"complain if -i but not --grep\" is probably not a\ngood idea. So in that case, I think this patch (allocating grep_filter\ninside the struct) _is_ a good idea.\n\nBut I don't feel too strongly either way. If you disagree, we can go\nwith the first one, and I can resend it (with the cleanup I mentioned)\nand I can do the trivial complaining patch on top of it.\n\n-Peff\n"},{"id":"88435","messageId":"7vzln1hann.fsf@gitster.siamese.dyndns.org","threadId":"15126","inReplyTo":"20080825061504.GA9313@coredump.intra.peff.net","subject":"Re: [PATCH] fix \"git log -i --grep\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-25T06:27:24Z","receivedAt":"2008-08-25T06:27:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I worked up this patch, and it is below. However, I think it may not be\n> a good idea, because...\n>\n>> The only issue I still have, which I suspect your fix has made it easier\n>> to address, is to complain if sub-options to grep like -i and -E are given\n>> without --grep. That's not something v1.5.6 series did, though.\n>\n> This is trivial with my first patch, but not with the second. With\n> grep_filter kept as a pointer, we know that if the pointer is non-NULL\n> but there are no patterns, then the user asked for grep options but\n> never --grep.\n\nHmm, that's true --- instead you would need to introduce a new flag in\nrev_info that records if you saw any grep sub-options, if we want to check\nthis condition.\n\n> I guess this might be a helpful thing for some users, but I wonder if it\n> is being too unpredictable for script usage. I.e., a script like:\n>\n> git log -E `for i in \"$@\"; do echo --author=$i`\n\nOk, that's true, so let's not worry about making \"log -i without --grep\"\nan error.\n\n> Anyway, the non-allocating patch is below. Aside from the test case, it\n> deletes more lines than it adds, which is always nice.\n\nYeah, thanks.\n"},{"id":"88555","messageId":"48B3B8B0.4020609@fastmail.fm","threadId":"15126","inReplyTo":"20080822211902.GA31884@coredump.intra.peff.net","subject":"[PATCH v2] allow user aliases for the --author parameter","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-26T08:02:56Z","receivedAt":"2008-08-26T08:02:56Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"This allows the use of author abbreviations when specifying commit\nauthors via the --author option to git commit. \"--author=$key\" is\nresolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\nconfig.\n\nIn an ideal word, all my collaborators would exchange changes as git\npatches (or even via pull/push). In the real world, they send new\nversions which I integrate (after dealing with their whitespace and\nencoding changes...). Therefore, being able to say \"git commit\n--author=mickey\" and having git translate \"mickey\" into \"Mickey Mouse\n\" is a real time saver. The patch accomplishes\nthis by reading config keys \"user.mickey.name\" and \"user.mickey.email\"\nwhen encountering an --author argument without \"<>\".\n\nSigned-off-by: Michael J Gruber \n---\n\nI tried to apply everything I've learned from this thread:\n- Justification in commit message rather than cover\n- minor style adjustments\n- xstrdup two more strings to spare future leakage cleanup-a-thons a few\n unpleasant surprises\n- comes with documentation patch now\n\nI think the relation to and distinction from \"git-svn -A\" and \".mailmap\"\nhas become clear through the discussion (should a summary go in the commit\nmessage?).\nI really like Junio's alias (git who). It's certainly helpful. For the\ncase of \"git commit --author key\" I think we should not simply go by the\nfirst, possibly non-unique match returned by \"git show\". Also, being able\nto say \"git commit --author=nitpicker\" may make some days brighter ;)\n\n Documentation/config.txt | 8 +++++\n Documentation/git-commit.txt | 5 ++-\n builtin-commit.c | 67 +++++++++++++++++++++++++++++++++++++++++-\n 3 files changed, 78 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 9020675..9bea3a3 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1107,6 +1107,14 @@ user.signingkey::\n \tunchanged to gpg's --local-user parameter, so you may specify a key\n \tusing any method that gpg supports.\n \n+user..email::\n+\tThe email address to be recorded in a newly created commit if you\n+\tspecify the option \\--author= to linkgit:git-commit[1].\n+\n+user..name::\n+\tThe full name to be recorded in a newly created commit if you\n+\tspecify the option \\--author= to linkgit:git-commit[1].\n+\n imap::\n \tThe configuration variables in the 'imap' section are described\n \tin linkgit:git-imap-send[1].\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 0e25bb8..1685cf6 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -76,7 +76,10 @@ OPTIONS\n \n --author=::\n \tOverride the author name used in the commit. Use\n-\t`A U Thor ` format.\n+\t`A U Thor ` format. Alternatively, if\n+\t does not contain `<>` then the configuration\n+\tvariables `user..name` and `user..email`\n+\tare used if present (see linkgit:git-config[1]).\n \n -m ::\n --message=::\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 649c8be..c36e60f 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -53,6 +53,14 @@ static char *author_name, *author_email, *author_date;\n static int all, edit_flag, also, interactive, only, amend, signoff;\n static int quiet, verbose, no_verify, allow_empty;\n static char *untracked_files_arg;\n+struct user {\n+\tchar *name;\n+\tchar *full_name;\n+\tchar *email;\n+};\n+static struct user **users;\n+static int users_alloc;\n+static int users_nr;\n /*\n * The default commit message cleanup mode will remove the lines\n * beginning with # (shell comments) and leading and trailing\n@@ -406,6 +414,7 @@ static const char sign_off_header[] = \"Signed-off-by: \";\n static void determine_author_info(void)\n {\n \tchar *name, *email, *date;\n+\tint i;\n \n \tname = getenv(\"GIT_AUTHOR_NAME\");\n \temail = getenv(\"GIT_AUTHOR_EMAIL\");\n@@ -429,10 +438,22 @@ static void determine_author_info(void)\n \t\tdate = xstrndup(rb + 2, eol - (rb + 2));\n \t}\n \n+\tauthor_date = date;\n+\n \tif (force_author) {\n \t\tconst char *lb = strstr(force_author, \" <\");\n \t\tconst char *rb = strchr(force_author, '>');\n \n+\t\tif (!lb && !rb) {\n+\t\t\tfor (i = 0; i < users_nr; i++) {\n+\t\t\t\tif (!strcmp(force_author, users[i]->name)) {\n+\t\t\t\t\tauthor_name = xstrdup(users[i]->full_name);\n+\t\t\t\t\tauthor_email = xstrdup(users[i]->email);\n+\t\t\t\t\treturn;\n+\t\t\t\t}\n+\t\t\t}\n+\t\t}\n+\n \t\tif (!lb || !rb)\n \t\t\tdie(\"malformed --author parameter\");\n \t\tname = xstrndup(force_author, lb - force_author);\n@@ -441,7 +462,6 @@ static void determine_author_info(void)\n \n \tauthor_name = name;\n \tauthor_email = email;\n-\tauthor_date = date;\n }\n \n static int prepare_to_commit(const char *index_file, const char *prefix)\n@@ -888,11 +908,56 @@ static void print_summary(const char *prefix, const unsigned char *sha1)\n \t}\n }\n \n+static struct user *make_user(const char *name, int len)\n+{\n+\tstruct user *ret;\n+\tint i;\n+\n+\tfor (i = 0; i < users_nr; i++) {\n+\t\tif (len ? (!strncmp(name, users[i]->name, len) &&\n+\t\t\t !users[i]->name[len]) :\n+\t\t !strcmp(name, users[i]->name))\n+\t\t\treturn users[i];\n+\t}\n+\n+\tALLOC_GROW(users, users_nr + 1, users_alloc);\n+\tret = xcalloc(1, sizeof(struct user));\n+\tusers[users_nr++] = ret;\n+\tif (len)\n+\t\tret->name = xstrndup(name, len);\n+\telse\n+\t\tret->name = xstrdup(name);\n+\n+\treturn ret;\n+}\n+\n static int git_commit_config(const char *k, const char *v, void *cb)\n {\n+\tconst char *name;\n+\tconst char *subkey;\n+\tstruct user *user;\n+\n \tif (!strcmp(k, \"commit.template\"))\n \t\treturn git_config_string(&template_file, k, v);\n \n+\tif (!prefixcmp(k, \"user.\")) {\n+\t\tname = k + 5;\n+\t\tsubkey = strrchr(name, '.');\n+\t\tif (!subkey)\n+\t\t\treturn 0;\n+\t\tuser = make_user(name, subkey - name);\n+\t\tif (!strcmp(subkey, \".name\")) {\n+\t\t\tif (!v)\n+\t\t\t\treturn config_error_nonbool(k);\n+\t\t\tuser->full_name = xstrdup(v);\n+\t\t} else if (!strcmp(subkey, \".email\")) {\n+\t\t\tif (!v)\n+\t\t\t\treturn config_error_nonbool(k);\n+\t\t\tuser->email = xstrdup(v);\n+\t\t}\n+\t\treturn 0;\n+\t}\n+\n \treturn git_status_config(k, v, cb);\n }\n \n-- \n1.6.0\n"},{"id":"88665","messageId":"7vsksr1hgt.fsf@gitster.siamese.dyndns.org","threadId":"15126","inReplyTo":"48B3B8B0.4020609@fastmail.fm","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-26T23:31:30Z","receivedAt":"2008-08-26T23:31:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> This allows the use of author abbreviations when specifying commit\n> authors via the --author option to git commit. \"--author=$key\" is\n> resolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\n> config.\n\nMaybe it is just me, but I am hesitant about the contamination of user.*\nconfiguration namespace. This patch as a general solution does not scale\nwell, once you start working with more than a few dozen people.\n\nWhy was it insufficient to use an external shortname-to-fullname mapping\nfile like git-svn and git-cvsimport does, again?\n"},{"id":"88671","messageId":"20080827001944.GA7347@coredump.intra.peff.net","threadId":"15126","inReplyTo":"7vsksr1hgt.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-27T00:19:45Z","receivedAt":"2008-08-27T00:19:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:\n\n> > This allows the use of author abbreviations when specifying commit\n> > authors via the --author option to git commit. \"--author=$key\" is\n> > resolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\n> > config.\n> \n> Maybe it is just me, but I am hesitant about the contamination of user.*\n> configuration namespace. This patch as a general solution does not scale\n> well, once you start working with more than a few dozen people.\n\nIt is not just you. I think this version of the patch is much improved,\nbut I am still against user.$key.*. At the very least, it needs its own\nnamespace.\n\nI think if somebody cares, reading external files of various formats\nwould be nice (and a simple \"alias, space, expansion, newline\" format\ncould be introduced), but since I am not volunteering to implement that,\nthis even simpler implementation is acceptable to me, as long as it is\nuser.alias.$key.* or similar.\n\n-Peff\n"},{"id":"88690","messageId":"7v7ia3rnnq.fsf@gitster.siamese.dyndns.org","threadId":"15126","inReplyTo":"20080827001944.GA7347@coredump.intra.peff.net","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-27T06:13:13Z","receivedAt":"2008-08-27T06:13:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Aug 26, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:\n>\n>> > This allows the use of author abbreviations when specifying commit\n>> > authors via the --author option to git commit. \"--author=$key\" is\n>> > resolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\n>> > config.\n>> \n>> Maybe it is just me, but I am hesitant about the contamination of user.*\n>> configuration namespace. This patch as a general solution does not scale\n>> well, once you start working with more than a few dozen people.\n>\n> It is not just you. I think this version of the patch is much improved,\n> but I am still against user.$key.*. At the very least, it needs its own\n> namespace.\n\nIt's not just that. Having many of these in .git/config will slow down\nany unrelated thing that needs to read from config.\n\nI am not married to the \"reuse existing information\" idea, but doing it\nthe way this sample patch does at least makes only people who uses this\nfeature to pay the price and only when they use it.\n\nNot extensively tested, beyond the usual test suite, and using it for real\nonly once to commit this with \"git commit --author=Jeff\". I wanted to say\n\"Michael J\" instead, but there is this little chicken-and-egg problem ;-)\n\n builtin-commit.c | 27 +++++++++++++++++++++++++++\n 1 files changed, 27 insertions(+), 0 deletions(-)\n\ndiff --git c/builtin-commit.c w/builtin-commit.c\nindex 649c8be..8aae906 100644\n--- c/builtin-commit.c\n+++ w/builtin-commit.c\n@@ -710,6 +710,30 @@ static int message_is_empty(struct strbuf *sb, int start)\n \treturn 1;\n }\n \n+static const char *find_author_by_nickname(const char *name)\n+{\n+\tstruct rev_info revs;\n+\tstruct commit *commit;\n+\tstruct strbuf buf = STRBUF_INIT;\n+\tconst char *av[20];\n+\tint ac = 0;\n+\n+\tinit_revisions(&revs, NULL);\n+\tstrbuf_addf(&buf, \"--author=%s\", name);\n+\tav[++ac] = \"--all\";\n+\tav[++ac] = buf.buf;\n+\tav[++ac] = NULL;\n+\tsetup_revisions(ac, av, &revs, NULL);\n+\tprepare_revision_walk(&revs);\n+\tcommit = get_revision(&revs);\n+\tif (commit) {\n+\t\tstrbuf_release(&buf);\n+\t\tformat_commit_message(commit, \"%an <%ae>\", &buf);\n+\t\treturn strbuf_detach(&buf, NULL);\n+\t}\n+\tdie(\"No existing author found with '%s'\", name);\n+}\n+\n static int parse_and_validate_options(int argc, const char *argv[],\n \t\t\t\t const char * const usage[],\n \t\t\t\t const char *prefix)\n@@ -720,6 +744,9 @@ static int parse_and_validate_options(int argc, const char *argv[],\n \tlogfile = parse_options_fix_filename(prefix, logfile);\n \ttemplate_file = parse_options_fix_filename(prefix, template_file);\n \n+\tif (force_author && !strchr(force_author, '>'))\n+\t\tforce_author = find_author_by_nickname(force_author);\n+\n \tif (logfile || message.len || use_message)\n \t\tuse_editor = 0;\n \tif (edit_flag)\n"},{"id":"88714","messageId":"48B52037.7030405@fastmail.fm","threadId":"15126","inReplyTo":"7v7ia3rnnq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-27T09:36:55Z","receivedAt":"2008-08-27T09:36:55Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 27.08.2008 08:13:\n> Jeff King writes:\n> \n>> On Tue, Aug 26, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:\n>>\n>>>> This allows the use of author abbreviations when specifying commit\n>>>> authors via the --author option to git commit. \"--author=$key\" is\n>>>> resolved by looking up \"user.$key.name\" and \"user.$key.email\" in the\n>>>> config.\n>>> Maybe it is just me, but I am hesitant about the contamination of user.*\n>>> configuration namespace. This patch as a general solution does not scale\n>>> well, once you start working with more than a few dozen people.\n>> It is not just you. I think this version of the patch is much improved,\n>> but I am still against user.$key.*. At the very least, it needs its own\n>> namespace.\n> \n> It's not just that. Having many of these in .git/config will slow down\n> any unrelated thing that needs to read from config.\n\nI don't see a namespace problem as long as nobody uses \"name\" or \"email\"\nas $key. That said I'd suggest useralias.$key.{name,email} then which\ngives a cleaner separation and leaves the possibility to\n\n- use the alias for other cases than --author\n- use other fields than name, email\n\nat a later time.\n\n> I am not married to the \"reuse existing information\" idea, but doing it\n> the way this sample patch does at least makes only people who uses this\n> feature to pay the price and only when they use it.\n\nPeople who don't use this feature don't have any entries and don't pay\nanything.\nPeople who use this feature and have a moderate number of entries don't\npay a recognizable price.\nPeople who use this feature and have a vast amount of entries should be\ntold to implement an alias file parser ;)\n\n> Not extensively tested, beyond the usual test suite, and using it for real\n> only once to commit this with \"git commit --author=Jeff\". I wanted to say\n> \"Michael J\" instead, but there is this little chicken-and-egg problem ;-)\n[patch snipped]\n\nI'd be happy with that approach as well for my use case. In general it\nmay suffer from the uniqueness problem: If there's a recent commit\nauthored by \"Michael@Jeff.com\" your \"--author=Jeff\" will resolve\ndifferently from yesterday, and you won't even notice (not even commit\n-v tells you). [ A typo is punished by a search through all commits;\nthat's fine.]\n\nBut I won't compete with an alternative patch from The Man, of course ;)\n\n+\tdie(\"No existing author found with '%s'\", name);\nMinor suggestion:\n\"...or malformed --author parameter\"\nI foresee questions like \"Huh? What does it mean not existing\" when\npeople don't get the A U Thor format right.\n\nMichael\n"},{"id":"88721","messageId":"20080827122954.GA11986@coredump.intra.peff.net","threadId":"15126","inReplyTo":"7v7ia3rnnq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-27T12:29:54Z","receivedAt":"2008-08-27T12:29:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2008 at 11:13:13PM -0700, Junio C Hamano wrote:\n\n> > It is not just you. I think this version of the patch is much improved,\n> > but I am still against user.$key.*. At the very least, it needs its own\n> > namespace.\n> \n> It's not just that. Having many of these in .git/config will slow down\n> any unrelated thing that needs to read from config.\n\nSure, it can, but so can putting a lot of branch info in your config. My\nthinking was that this covers the \"I just want to put in a few entries\neasily\" use case. If somebody wants to do something _big_, then that is\ntime for the external format.\n\nBut then we have two formats which we must support forever, which is\nmaybe a bad thing.\n\n> I am not married to the \"reuse existing information\" idea, but doing it\n> the way this sample patch does at least makes only people who uses this\n> feature to pay the price and only when they use it.\n\nActually, I like this quite a bit. Almost by definition, the information\nis already here (and if it isn't, it is because it is the first time\nthis person is an author, so you would have to end up typing it once\n_anyway_).\n\nMy only complaint is:\n\n> +\tstrbuf_addf(&buf, \"--author=%s\", name);\n> +\tav[++ac] = \"--all\";\n> +\tav[++ac] = buf.buf;\n> +\tav[++ac] = NULL;\n\nI am too lazy to hit \"shift\", so I would use \"-i\".\n\n-Peff\n"},{"id":"88723","messageId":"20080827124010.GA13094@coredump.intra.peff.net","threadId":"15126","inReplyTo":"48B52037.7030405@fastmail.fm","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-27T12:40:10Z","receivedAt":"2008-08-27T12:40:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[resend, copy git list. Gah, Michael there is something about your\nmessages that causes me to keep dropping the git list when I reply. It\nlooks like maybe you send one message to the author without git@vger\ncc'd, and then you send a different one 'to' the git list without the\noriginal 'from' in the cc?]\n\nOn Wed, Aug 27, 2008 at 11:36:55AM +0200, Michael J Gruber wrote:\n\n> I don't see a namespace problem as long as nobody uses \"name\" or \"email\"\n> as $key.\n\nIt also ties our hands for putting more things in user.* later, since\nnow we will hurt users who have put their arbitrary aliases in user.*\n(and who will rightly complain when we break their config).\n\n> That said I'd suggest useralias.$key.{name,email} then which gives a\n> cleaner separation and leaves the possibility to\n\nI would be fine with that. Though I do think Junio's \"automatic\" version\nis even nicer.\n\n> - use the alias for other cases than --author - use other fields than\n> name, email\n\nI think the big user would be send-email; I don't know if that will ever\nget converted to C, though.\n\n> People who don't use this feature don't have any entries and don't pay\n> anything.\n> People who use this feature and have a moderate number of entries don't\n> pay a recognizable price.\n> People who use this feature and have a vast amount of entries should be\n> told to implement an alias file parser ;)\n\nThis I agree with. :)\n\n> I'd be happy with that approach as well for my use case. In general it\n> may suffer from the uniqueness problem: If there's a recent commit\n> authored by \"Michael@Jeff.com\" your \"--author=Jeff\" will resolve\n> differently from yesterday, and you won't even notice (not even commit\n> -v tells you). [ A typo is punished by a search through all commits;\n> that's fine.]\n\nThe commit message template should say:\n\n Author: A U Thor \n\nbut of course you won't see that if you are using \"-m\".\n\nI wonder if there is a good way to warn that we have multiple matches.\nOf course we expect many _exact_ matches if the author has multiple\ncommits, but we could look for distinct matches. However, even that will\nturn up false positives, since some authors have multiple email\naddresses.\n\n-Peff\n"},{"id":"88733","messageId":"20080827171846.GA14300@coredump.intra.peff.net","threadId":"15126","inReplyTo":"7vmyiyqt08.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-27T17:18:46Z","receivedAt":"2008-08-27T17:18:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 27, 2008 at 10:15:19AM -0700, Junio C Hamano wrote:\n\n> > I wonder if there is a good way to warn that we have multiple matches.\n> > Of course we expect many _exact_ matches if the author has multiple\n> > commits, but we could look for distinct matches. However, even that will\n> > turn up false positives, since some authors have multiple email\n> > addresses.\n> \n> In order to prove unique match you would need an exhaustive check, don't\n> you?\n\nYes, though you also do exhaustive check in the worst case already (when\nthe name doesn't match anything). It takes about .7s on a warm cache on\nmy git.git.\n\nAnyway, I think it is already not a good idea because of the semantics,\nlet alone the performance.\n\n-Peff\n\nPS Your message also didn't go to git@vger, so I think you are having\nthe same problem with Michael's message that I am.\n"},{"id":"88734","messageId":"7viqtmqstu.fsf@gitster.siamese.dyndns.org","threadId":"15126","inReplyTo":"20080827122954.GA11986@coredump.intra.peff.net","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-27T17:19:09Z","receivedAt":"2008-08-27T17:19:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> My only complaint is:\n>\n>> +\tstrbuf_addf(&buf, \"--author=%s\", name);\n>> +\tav[++ac] = \"--all\";\n>> +\tav[++ac] = buf.buf;\n>> +\tav[++ac] = NULL;\n>\n> I am too lazy to hit \"shift\", so I would use \"-i\".\n\nI thought about it after writing the one you saw on the list, but from the\nbeginning I was planning to do this merely as a demonstration patch that\nsomebody who is interested in the feature can polish and resubmit with\ntest and documentation. I didn't bother adding such frills --- that is\npart of \"polish and resubmit\" cycle.\n"},{"id":"88994","messageId":"48B66783.4050305@fastmail.fm","threadId":"15126","inReplyTo":"20080827171846.GA14300@coredump.intra.peff.net","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-28T08:53:23Z","receivedAt":"2008-08-28T08:53:23Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 27.08.2008 19:18:\n> On Wed, Aug 27, 2008 at 10:15:19AM -0700, Junio C Hamano wrote:\n> \n>>> I wonder if there is a good way to warn that we have multiple matches.\n>>> Of course we expect many _exact_ matches if the author has multiple\n>>> commits, but we could look for distinct matches. However, even that will\n>>> turn up false positives, since some authors have multiple email\n>>> addresses.\n>> In order to prove unique match you would need an exhaustive check, don't\n>> you?\n> \n> Yes, though you also do exhaustive check in the worst case already (when\n> the name doesn't match anything). It takes about .7s on a warm cache on\n> my git.git.\n> \n> Anyway, I think it is already not a good idea because of the semantics,\n> let alone the performance.\n\nBy \"it\" you are referring to\n- checking for uniqueness or\n- the whole approach combing through commits?\n\nI'd be happy with the patch as is (+\"-i\" maybe) now that I understand\nthe template... (I tried --author=key with a key expanding to the\n(default) committer, in which case the commit template does not show\nauthor nor committer. Duh.)\n\n> -Peff\n> \n> PS Your message also didn't go to git@vger, so I think you are having\n> the same problem with Michael's message that I am.\n\nOK: I send this To: Jeff, Cc: Junio, Nntp:\ngmane.comp.version-control.git (using Thunderbird 2). (This is the\nresult of hitting \"reply all\" and deleting git@vger, because it's\nduplicated by gmane...git.)\n\nCould the two of you please tell me what you are receiving? I'm sorry\nfor this, but if this is a systematic problem with gmane I should switch\n(and others should be warned); if it's a TB thing I will cope.\n\nMichael\n"},{"id":"89014","messageId":"20080828213322.GB27867@coredump.intra.peff.net","threadId":"15126","inReplyTo":"48B66783.4050305@fastmail.fm","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-28T21:33:22Z","receivedAt":"2008-08-28T21:33:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 10:53:23AM +0200, Michael J Gruber wrote:\n\n> > Anyway, I think it is already not a good idea because of the semantics,\n> > let alone the performance.\n> \n> By \"it\" you are referring to\n> - checking for uniqueness or\n> - the whole approach combing through commits?\n\nSorry, I meant \"checking for uniqueness.\" I think combing through is a\nfine idea, but checking for uniqueness will come up with false\npositives.\n\n> I'd be happy with the patch as is (+\"-i\" maybe) now that I understand\n> the template... (I tried --author=key with a key expanding to the\n> (default) committer, in which case the commit template does not show\n> author nor committer. Duh.)\n\nYou could pull the first from either (I think you will have to look at\nthe revision.c code at a little bit lower level -- look at how --author\nadds grep fields). In a patch-by-mail repository like git.git, Junio is\nalmost always the committer. But other projects will have different\nworkflows.\n\n> > PS Your message also didn't go to git@vger, so I think you are having\n> > the same problem with Michael's message that I am.\n> \n> OK: I send this To: Jeff, Cc: Junio, Nntp:\n> gmane.comp.version-control.git (using Thunderbird 2). (This is the\n> result of hitting \"reply all\" and deleting git@vger, because it's\n> duplicated by gmane...git.)\n\nAh, OK. So your message ends up in my mailbox without a mention of\ngit@vger at all. It of course has a \"newsgroups\" header, but that is not\nhelpful for people who do not use gmane at all. And given that this is\nprimarily a mailing list which has a newsgroup interface, and not vice\nversa, I think it makes sense to give priority to the mail interface.\n\nIs there a reason to post through gmane at all? Why not just leave the\ngit@vger cc, and kill the nntp post?\n\n-Peff\n"},{"id":"89015","messageId":"20080828213643.GC27867@coredump.intra.peff.net","threadId":"15126","inReplyTo":"48B65922.4050005@fastmail.fm","subject":"Re: [PATCH v2] allow user aliases for the --author parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-28T21:36:43Z","receivedAt":"2008-08-28T21:36:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 09:52:02AM +0200, Michael J Gruber wrote:\n\n> Junio C Hamano venit, vidit, dixit 27.08.2008 19:13:\n> > Michael J Gruber writes:\n> > \n> >> People who don't use this feature don't have any entries and don't pay\n> >> anything. People who use this feature and have a moderate number of\n> >> entries don't pay a recognizable price. People who use this feature and\n> >> have a vast amount of entries should be told to implement an alias file\n> >> parser ;)\n> > \n> > That attitude is Ok for an experimental piece of software. Perhaps it was\n> > Ok for git 18 months ago as well, but not anymore.\n> \n> I probably should have put the ;) in emphasis. This is not my attitude.\n\nHmm. It sounds like we your interest is moving towards Junio's approach,\nso maybe this doesn't matter. But I actually think your statement above\nmade some sense. I think we will be providing multiple sources of alias\ninformation in the long run anyway, so this becomes just another source.\nAs a source, it has some advantages (it is simple to setup in your\nexisting git config, and does not require an extra file), and some\ndisadvantages (it does not scale as well as some other solutions).\n\n> P.S.: This is \"reply all\" to a mail sent off-list probably meant for the\n> list, but I didn't want to cc: the list without your consent (since I'm\n> quoting you). I'm sorry for this confusion. I'm sure it's not your MUAs\n> and confident it's not mine, which leaves gmane..\n\nI am putting it back on-list. :)\n\n-Peff\n"}]}