{"thread":{"id":"49280","subject":"[RFC PATCH v2] Allow aliases that include other aliases","startedAt":"2018-09-05T08:54:38Z","lastAt":"2018-10-29T14:17:09Z","messageCount":52,"participants":["Tim Schumacher","Duy Nguyen","Junio C Hamano","Jeff King","Ævar Arnfjörð Bjarmason","Eric Sunshine"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"357409","messageId":"20180905085427.4099-1-timschumi@gmx.de","threadId":"49280","inReplyTo":null,"subject":"[RFC PATCH v2] Allow aliases that include other aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-05T08:54:27Z","receivedAt":"2018-09-05T08:54:38Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"Aliases can only contain non-alias git commands and their\narguments, not other user-defined aliases. Resolving further\n(nested) aliases is prevented by breaking the loop after the\nfirst alias was processed. Git then fails with a command-not-found\nerror.\n\nAllow resolving nested aliases by not breaking the loop in\nrun_argv() after the first alias was processed. Instead, continue\nincrementing `done_alias` until `handle_alias()` fails, which means that\nthere are no further aliases that can be processed. Prevent looping\naliases by storing substituted commands in `cmd_list` and checking if\na command has been substituted previously.\n---\n\nThis is what I've come up with to prevent looping aliases. I'm not too\nhappy with the number of indentations needed, but this seemed to be the\neasiest way to search an array for a value.\n\n---\n git.c | 25 ++++++++++++++++++++++---\n 1 file changed, 22 insertions(+), 3 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex c27c38738..fd90a3341 100644\n--- a/git.c\n+++ b/git.c\n@@ -674,6 +674,8 @@ static void execv_dashed_external(const char **argv)\n static int run_argv(int *argcp, const char ***argv)\n {\n \tint done_alias = 0;\n+\tconst char **cmd_list = NULL;\n+\tint cmd_list_alloc = 0;\n \n \twhile (1) {\n \t\t/*\n@@ -691,17 +693,34 @@ static int run_argv(int *argcp, const char ***argv)\n \t\t/* .. then try the external ones */\n \t\texecv_dashed_external(*argv);\n \n+\t\t/* Increase the array size and add the current\n+\t\t * command to it.\n+\t\t */\n+\t\tcmd_list_alloc += strlen(*argv[0]) + 1;\n+\t\tREALLOC_ARRAY(cmd_list, cmd_list_alloc);\n+\t\tcmd_list[done_alias] = *argv[0];\n+\n+\t\t/* Search the array for occurrences of that command,\n+\t\t * abort if something has been found.\n+\t\t */\n+\t\tfor (int i = 0; i < done_alias; i++) {\n+\t\t\tif (!strcmp(cmd_list[i], *argv[0])) {\n+\t\t\t\tdie(\"loop alias: %s is called twice\",\n+\t\t\t\t cmd_list[done_alias]);\n+\t\t\t}\n+\t\t}\n+\n \t\t/* It could be an alias -- this works around the insanity\n \t\t * of overriding \"git log\" with \"git show\" by having\n \t\t * alias.log = show\n \t\t */\n-\t\tif (done_alias)\n-\t\t\tbreak;\n \t\tif (!handle_alias(argcp, argv))\n \t\t\tbreak;\n-\t\tdone_alias = 1;\n+\t\tdone_alias++;\n \t}\n \n+\tfree(cmd_list);\n+\n \treturn done_alias;\n }\n \n-- \n2.19.0.rc1.2.g8f4faccc1\n\n"},{"id":"357439","messageId":"CACsJy8BLEtBWyAuRBphv_PVisKao0YaBewKJXECEuCVzvk9qXg@mail.gmail.com","threadId":"49280","inReplyTo":"20180905085427.4099-1-timschumi@gmx.de","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-09-05T15:48:40Z","receivedAt":"2018-09-05T15:49:08Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Sep 5, 2018 at 10:56 AM Tim Schumacher wrote:\n>\n> Aliases can only contain non-alias git commands and their\n> arguments, not other user-defined aliases. Resolving further\n> (nested) aliases is prevented by breaking the loop after the\n> first alias was processed. Git then fails with a command-not-found\n> error.\n>\n> Allow resolving nested aliases by not breaking the loop in\n> run_argv() after the first alias was processed. Instead, continue\n> incrementing `done_alias` until `handle_alias()` fails, which means that\n> there are no further aliases that can be processed. Prevent looping\n> aliases by storing substituted commands in `cmd_list` and checking if\n> a command has been substituted previously.\n> ---\n>\n> This is what I've come up with to prevent looping aliases. I'm not too\n> happy with the number of indentations needed, but this seemed to be the\n> easiest way to search an array for a value.\n\nYou can just make all the new code a separate function, which reduces\nindentation.\n\nThere's another thing I wanted (but probably a wrong thing to want):\nif I define alias 'foo' in ~/.gitconfig, then I'd like to modify it in\nsome project by redefining it as alias.foo='foo --something' in\n$GIT_DIR/config. This results in alias loop, but the loop is broken by\nlooking up 'foo' from a higher level config file instead.\n\nThis is not easy to do, and as I mentioned, I'm not even sure if it's\na sane thing to do.\n\n> + /* Increase the array size and add the current\n> + * command to it.\n> + */\n\nI think this is pretty clear from the code, you don't need to add a\ncomment to explain how the next few lines work. Same comment for the\nnext comment block.\n\n> + cmd_list_alloc += strlen(*argv[0]) + 1;\n> + REALLOC_ARRAY(cmd_list, cmd_list_alloc);\n> + cmd_list[done_alias] = *argv[0];\n> +\n> + /* Search the array for occurrences of that command,\n> + * abort if something has been found.\n> + */\n> + for (int i = 0; i < done_alias; i++) {\n> + if (!strcmp(cmd_list[i], *argv[0])) {\n> + die(\"loop alias: %s is called twice\",\n\nPlease wrap the string in _() so that it can be translated in\ndifferent languages.\n\n> + cmd_list[done_alias]);\n> + }\n> + }\n> +\n-- \nDuy\n"},{"id":"357451","messageId":"xmqqlg8f50mq.fsf@gitster-ct.c.googlers.com","threadId":"49280","inReplyTo":"20180905085427.4099-1-timschumi@gmx.de","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-05T17:12:45Z","receivedAt":"2018-09-05T17:12:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tim Schumacher writes:\n\n> @@ -691,17 +693,34 @@ static int run_argv(int *argcp, const char ***argv)\n> \t\t/* .. then try the external ones */\n> \t\texecv_dashed_external(*argv);\n> \n> +\t\t/* Increase the array size and add the current\n> +\t\t * command to it.\n> +\t\t */\n> +\t\tcmd_list_alloc += strlen(*argv[0]) + 1;\n> +\t\tREALLOC_ARRAY(cmd_list, cmd_list_alloc);\n> +\t\tcmd_list[done_alias] = *argv[0];\n> +\n> +\t\t/* Search the array for occurrences of that command,\n> +\t\t * abort if something has been found.\n> +\t\t */\n> +\t\tfor (int i = 0; i < done_alias; i++) {\n> +\t\t\tif (!strcmp(cmd_list[i], *argv[0])) {\n> +\t\t\t\tdie(\"loop alias: %s is called twice\",\n> +\t\t\t\t cmd_list[done_alias]);\n> +\t\t\t}\n> +\t\t}\n> +\n\nWouldn't all of the above become three or four lines that is so\nclear that there is no need for any comment if you used string-list,\nperhaps?\n\n> \t\t/* It could be an alias -- this works around the insanity\n> \t\t * of overriding \"git log\" with \"git show\" by having\n> \t\t * alias.log = show\n> \t\t */\n\n\t/*\n\t * Style: our multi-line comment begins with and ends with\n\t * slash-asterisk and asterisk-slash on their own lines.\n\t */\n\n> -\t\tif (done_alias)\n> -\t\t\tbreak;\n> \t\tif (!handle_alias(argcp, argv))\n> \t\t\tbreak;\n> -\t\tdone_alias = 1;\n> +\t\tdone_alias++;\n> \t}\n> \n> +\tfree(cmd_list);\n> +\n> \treturn done_alias;\n> }\n"},{"id":"357457","messageId":"20180905173455.GA2336@sigill.intra.peff.net","threadId":"49280","inReplyTo":"20180905085427.4099-1-timschumi@gmx.de","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-05T17:34:55Z","receivedAt":"2018-09-05T17:34:59Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 05, 2018 at 10:54:27AM +0200, Tim Schumacher wrote:\n\n> Aliases can only contain non-alias git commands and their\n> arguments, not other user-defined aliases. Resolving further\n> (nested) aliases is prevented by breaking the loop after the\n> first alias was processed. Git then fails with a command-not-found\n> error.\n> \n> Allow resolving nested aliases by not breaking the loop in\n> run_argv() after the first alias was processed. Instead, continue\n> incrementing `done_alias` until `handle_alias()` fails, which means that\n> there are no further aliases that can be processed. Prevent looping\n> aliases by storing substituted commands in `cmd_list` and checking if\n> a command has been substituted previously.\n> ---\n> \n> This is what I've come up with to prevent looping aliases. I'm not too\n> happy with the number of indentations needed, but this seemed to be the\n> easiest way to search an array for a value.\n\nI think this approach is OK, though I wonder if we'd also be fine with\njust:\n\n if (done_alias++ > 100)\n\tdie(\"woah, is your alias looping?\");\n\nThe point is just to prevent a runaway infinite loop, and this does that\nwhile keeping the cost very low for the common case (not that one string\ninsertion is probably breaking the bank).\n\nIt could also extend to ! aliases if we wanted (i.e., my '!git foo'\nexample from earlier), but you'd have to carry the counter through the\nenvironment between processes.\n\n-Peff\n"},{"id":"357469","messageId":"5c618de8-6676-8fa4-fe19-4db44befd73c@gmx.de","threadId":"49280","inReplyTo":"CACsJy8BLEtBWyAuRBphv_PVisKao0YaBewKJXECEuCVzvk9qXg@mail.gmail.com","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-05T19:02:50Z","receivedAt":"2018-09-05T19:02:59Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"On 05.09.18 17:48, Duy Nguyen wrote:\n> On Wed, Sep 5, 2018 at 10:56 AM Tim Schumacher wrote:\n>>\n>> Aliases can only contain non-alias git commands and their\n>> arguments, not other user-defined aliases. Resolving further\n>> (nested) aliases is prevented by breaking the loop after the\n>> first alias was processed. Git then fails with a command-not-found\n>> error.\n>>\n>> Allow resolving nested aliases by not breaking the loop in\n>> run_argv() after the first alias was processed. Instead, continue\n>> incrementing `done_alias` until `handle_alias()` fails, which means that\n>> there are no further aliases that can be processed. Prevent looping\n>> aliases by storing substituted commands in `cmd_list` and checking if\n>> a command has been substituted previously.\n>> ---\n>>\n>> This is what I've come up with to prevent looping aliases. I'm not too\n>> happy with the number of indentations needed, but this seemed to be the\n>> easiest way to search an array for a value.\n> \n> You can just make all the new code a separate function, which reduces\n> indentation.\n\nThat would solve the issue, but I'm not sure if it is worth introducing\na new function exclusively for that. I didn't find anything about a\nmaximum indentation level in the code guidelines and since the new\nparts stay within the width limit (and is imo still readable), would it\nbe ok to keep it like that?\n\n> \n> There's another thing I wanted (but probably a wrong thing to want):\n> if I define alias 'foo' in ~/.gitconfig, then I'd like to modify it in\n> some project by redefining it as alias.foo='foo --something' in\n> $GIT_DIR/config. This results in alias loop, but the loop is broken by\n> looking up 'foo' from a higher level config file instead.\n> \n> This is not easy to do, and as I mentioned, I'm not even sure if it's\n> a sane thing to do.\n\nThe alias system is using the default functions of the config system,\nI assume that adding such a functionality is not possible, at least not\nwithout breaking compatibility.\n\n> \n>> + /* Increase the array size and add the current\n>> + * command to it.\n>> + */\n> \n> I think this is pretty clear from the code, you don't need to add a\n> comment to explain how the next few lines work. Same comment for the\n> next comment block.\n\nI'll remove them in v3.\n\n> \n>> + cmd_list_alloc += strlen(*argv[0]) + 1;\n>> + REALLOC_ARRAY(cmd_list, cmd_list_alloc);\n>> + cmd_list[done_alias] = *argv[0];\n>> +\n>> + /* Search the array for occurrences of that command,\n>> + * abort if something has been found.\n>> + */\n>> + for (int i = 0; i < done_alias; i++) {\n>> + if (!strcmp(cmd_list[i], *argv[0])) {\n>> + die(\"loop alias: %s is called twice\",\n> \n> Please wrap the string in _() so that it can be translated in\n> different languages.\n\nI'll do that in v3 as well.\n\n> \n>> + cmd_list[done_alias]);\n>> + }\n>> + }\n>> +\n\nThanks for reviewing!\n\nTim\n"},{"id":"357472","messageId":"42223280-d9be-904d-2804-86939ae25aaa@gmx.de","threadId":"49280","inReplyTo":"xmqqlg8f50mq.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-05T19:12:24Z","receivedAt":"2018-09-05T19:12:38Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"On 05.09.18 19:12, Junio C Hamano wrote:\n> Tim Schumacher writes:\n> \n>> @@ -691,17 +693,34 @@ static int run_argv(int *argcp, const char ***argv)\n>> \t\t/* .. then try the external ones */\n>> \t\texecv_dashed_external(*argv);\n>> \n>> +\t\t/* Increase the array size and add the current\n>> +\t\t * command to it.\n>> +\t\t */\n>> +\t\tcmd_list_alloc += strlen(*argv[0]) + 1;\n>> +\t\tREALLOC_ARRAY(cmd_list, cmd_list_alloc);\n>> +\t\tcmd_list[done_alias] = *argv[0];\n>> +\n>> +\t\t/* Search the array for occurrences of that command,\n>> +\t\t * abort if something has been found.\n>> +\t\t */\n>> +\t\tfor (int i = 0; i < done_alias; i++) {\n>> +\t\t\tif (!strcmp(cmd_list[i], *argv[0])) {\n>> +\t\t\t\tdie(\"loop alias: %s is called twice\",\n>> +\t\t\t\t cmd_list[done_alias]);\n>> +\t\t\t}\n>> +\t\t}\n>> +\n> \n> Wouldn't all of the above become three or four lines that is so\n> clear that there is no need for any comment if you used string-list,\n> perhaps?\n\nWhoops, I didn't know that string-list existed. I'll try reworking the\ncode to use that. Concerning the comments: I planned to remove them\nanyways since the code should be simple enough to be understood without\nthem already.\n\n> \n>> \t\t/* It could be an alias -- this works around the insanity\n>> \t\t * of overriding \"git log\" with \"git show\" by having\n>> \t\t * alias.log = show\n>> \t\t */\n> \n> \t/*\n> \t * Style: our multi-line comment begins with and ends with\n> \t * slash-asterisk and asterisk-slash on their own lines.\n> \t */\n\nI wasn't sure if I should have changed that (because I didn't introduce\nthat comment), but I can fix it in v3.\n\n> \n>> -\t\tif (done_alias)\n>> -\t\t\tbreak;\n>> \t\tif (!handle_alias(argcp, argv))\n>> \t\t\tbreak;\n>> -\t\tdone_alias = 1;\n>> +\t\tdone_alias++;\n>> \t}\n>> \n>> +\tfree(cmd_list);\n>> +\n>> \treturn done_alias;\n>> }\n> \n"},{"id":"357477","messageId":"cd9a3a74-fdd6-0fb5-ae22-41d552391478@gmx.de","threadId":"49280","inReplyTo":"20180905173455.GA2336@sigill.intra.peff.net","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-05T20:02:58Z","receivedAt":"2018-09-05T20:03:10Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"On 05.09.18 19:34, Jeff King wrote:\n> On Wed, Sep 05, 2018 at 10:54:27AM +0200, Tim Schumacher wrote:\n> \n>> Aliases can only contain non-alias git commands and their\n>> arguments, not other user-defined aliases. Resolving further\n>> (nested) aliases is prevented by breaking the loop after the\n>> first alias was processed. Git then fails with a command-not-found\n>> error.\n>>\n>> Allow resolving nested aliases by not breaking the loop in\n>> run_argv() after the first alias was processed. Instead, continue\n>> incrementing `done_alias` until `handle_alias()` fails, which means that\n>> there are no further aliases that can be processed. Prevent looping\n>> aliases by storing substituted commands in `cmd_list` and checking if\n>> a command has been substituted previously.\n>> ---\n>>\n>> This is what I've come up with to prevent looping aliases. I'm not too\n>> happy with the number of indentations needed, but this seemed to be the\n>> easiest way to search an array for a value.\n> \n> I think this approach is OK, though I wonder if we'd also be fine with\n> just:\n> \n> if (done_alias++ > 100)\n> \tdie(\"woah, is your alias looping?\");\n> \n> The point is just to prevent a runaway infinite loop, and this does that\n> while keeping the cost very low for the common case (not that one string\n> insertion is probably breaking the bank).\n\nI'd opt to use the list-approach instead of aborting when the\ncounter reaches 100 (or any other value), because it aborts\nat the earliest known looping point. I didn't run any tests\ncomparing both solutions, but I assume the list would perform\nfaster than the hard-limit, even if it requires slightly more\nmemory and lines of code.\n\nI hope that I can put the string-list struct to some use,\nso that the solution using lists becomes an equally good\nsolution code-wise.\n\n> \n> It could also extend to ! aliases if we wanted (i.e., my '!git foo'\n> example from earlier), but you'd have to carry the counter through the\n> environment between processes.\n\nThat is a question about \"shooting oneself in the foot\" again,\nbut I think trying to prevent that would require more changes\nthan I can make, and it is definitely out-of-scope for this\npatch.\n\n> \n> -Peff\n> \nThanks for reviewing,\n\nTim\n"},{"id":"357485","messageId":"xmqqpnxr396a.fsf@gitster-ct.c.googlers.com","threadId":"49280","inReplyTo":"20180905173455.GA2336@sigill.intra.peff.net","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-05T21:51:09Z","receivedAt":"2018-09-05T21:51:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> This is what I've come up with to prevent looping aliases. I'm not too\n>> happy with the number of indentations needed, but this seemed to be the\n>> easiest way to search an array for a value.\n>\n> I think this approach is OK, though I wonder if we'd also be fine with\n> just:\n>\n> if (done_alias++ > 100)\n> \tdie(\"woah, is your alias looping?\");\n>\n> The point is just to prevent a runaway infinite loop, and this does that\n> while keeping the cost very low for the common case (not that one string\n> insertion is probably breaking the bank).\n\nYeah, as a hack, I guess the simpler the solution, the better it\nwould be.\n\n"},{"id":"357524","messageId":"20180906101658.1865-1-timschumi@gmx.de","threadId":"49280","inReplyTo":"20180905085427.4099-1-timschumi@gmx.de","subject":"[PATCH v3] Allow aliases that include other aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-06T10:16:58Z","receivedAt":"2018-09-06T10:17:15Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"Aliases can only contain non-alias git commands and their\narguments, not other user-defined aliases. Resolving further\n(nested) aliases is prevented by breaking the loop after the\nfirst alias was processed. Git then fails with a command-not-found\nerror.\n\nAllow resolving nested aliases by not breaking the loop in\nrun_argv() after the first alias was processed. Instead, continue\nincrementing `done_alias` until `handle_alias()` fails, which means that\nthere are no further aliases that can be processed. Prevent looping\naliases by storing substituted commands in `cmd_list` and checking if\na command has been substituted previously.\n\nWhile we're at it, fix a styling issue just below the added code.\n---\n git.c | 15 +++++++++++----\n 1 file changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex c27c38738..64f5fbd57 100644\n--- a/git.c\n+++ b/git.c\n@@ -674,6 +674,7 @@ static void execv_dashed_external(const char **argv)\n static int run_argv(int *argcp, const char ***argv)\n {\n \tint done_alias = 0;\n+\tstruct string_list cmd_list = STRING_LIST_INIT_NODUP;\n \n \twhile (1) {\n \t\t/*\n@@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)\n \t\t/* .. then try the external ones */\n \t\texecv_dashed_external(*argv);\n \n-\t\t/* It could be an alias -- this works around the insanity\n+\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n+\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n+\n+\t\tstring_list_append(&cmd_list, *argv[0]);\n+\n+\t\t/*\n+\t\t * It could be an alias -- this works around the insanity\n \t\t * of overriding \"git log\" with \"git show\" by having\n \t\t * alias.log = show\n \t\t */\n-\t\tif (done_alias)\n-\t\t\tbreak;\n \t\tif (!handle_alias(argcp, argv))\n \t\t\tbreak;\n-\t\tdone_alias = 1;\n+\t\tdone_alias++;\n \t}\n \n+\tstring_list_clear(&cmd_list, 0);\n+\n \treturn done_alias;\n }\n \n-- \n2.19.0.rc1.2.g8008c49c4.dirty\n\n"},{"id":"357529","messageId":"87r2i6rbiy.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"cd9a3a74-fdd6-0fb5-ae22-41d552391478@gmx.de","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-06T13:38:45Z","receivedAt":"2018-09-06T13:38:50Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Sep 05 2018, Tim Schumacher wrote:\n\n> On 05.09.18 19:34, Jeff King wrote:\n>> On Wed, Sep 05, 2018 at 10:54:27AM +0200, Tim Schumacher wrote:\n>>\n>>> Aliases can only contain non-alias git commands and their\n>>> arguments, not other user-defined aliases. Resolving further\n>>> (nested) aliases is prevented by breaking the loop after the\n>>> first alias was processed. Git then fails with a command-not-found\n>>> error.\n>>>\n>>> Allow resolving nested aliases by not breaking the loop in\n>>> run_argv() after the first alias was processed. Instead, continue\n>>> incrementing `done_alias` until `handle_alias()` fails, which means that\n>>> there are no further aliases that can be processed. Prevent looping\n>>> aliases by storing substituted commands in `cmd_list` and checking if\n>>> a command has been substituted previously.\n>>> ---\n>>>\n>>> This is what I've come up with to prevent looping aliases. I'm not too\n>>> happy with the number of indentations needed, but this seemed to be the\n>>> easiest way to search an array for a value.\n>>\n>> I think this approach is OK, though I wonder if we'd also be fine with\n>> just:\n>>\n>> if (done_alias++ > 100)\n>> \tdie(\"woah, is your alias looping?\");\n>>\n>> The point is just to prevent a runaway infinite loop, and this does that\n>> while keeping the cost very low for the common case (not that one string\n>> insertion is probably breaking the bank).\n>\n> I'd opt to use the list-approach instead of aborting when the\n> counter reaches 100 (or any other value), because it aborts\n> at the earliest known looping point. I didn't run any tests\n> comparing both solutions, but I assume the list would perform\n> faster than the hard-limit, even if it requires slightly more\n> memory and lines of code.\n\nI agree that this use of a list is better for a completely different\nreason (which I'll comment on in the v4 thread), but this reason doesn't\nmake any sense to me.\n\nIf we're looking at performance we're paying a fixed performance cost\nfor storing this list of strings over a counter for everything we do\nwith aliases.\n\nIt only helps over a counter for the case where we do have a loop, but\nat that point who cares? We're going to exit with an erro anyway and the\nuser has to fix his config, it doesn't matter if that error happens 1\nmillisecond earlier.\n"},{"id":"357530","messageId":"87pnxqrags.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"20180906101658.1865-1-timschumi@gmx.de","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-06T14:01:39Z","receivedAt":"2018-09-06T14:01:45Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Sep 06 2018, Tim Schumacher wrote:\n\n> Aliases can only contain non-alias git commands and their\n> arguments, not other user-defined aliases. Resolving further\n> (nested) aliases is prevented by breaking the loop after the\n> first alias was processed. Git then fails with a command-not-found\n> error.\n>\n> Allow resolving nested aliases by not breaking the loop in\n> run_argv() after the first alias was processed. Instead, continue\n> incrementing `done_alias` until `handle_alias()` fails, which means that\n> there are no further aliases that can be processed. Prevent looping\n> aliases by storing substituted commands in `cmd_list` and checking if\n> a command has been substituted previously.\n>\n> While we're at it, fix a styling issue just below the added code.\n> ---\n> git.c | 15 +++++++++++----\n> 1 file changed, 11 insertions(+), 4 deletions(-)\n>\n> diff --git a/git.c b/git.c\n> index c27c38738..64f5fbd57 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -674,6 +674,7 @@ static void execv_dashed_external(const char **argv)\n> static int run_argv(int *argcp, const char ***argv)\n> {\n> \tint done_alias = 0;\n> +\tstruct string_list cmd_list = STRING_LIST_INIT_NODUP;\n>\n> \twhile (1) {\n> \t\t/*\n> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)\n> \t\t/* .. then try the external ones */\n> \t\texecv_dashed_external(*argv);\n>\n> -\t\t/* It could be an alias -- this works around the insanity\n> +\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n> +\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n> +\n> +\t\tstring_list_append(&cmd_list, *argv[0]);\n> +\n> +\t\t/*\n> +\t\t * It could be an alias -- this works around the insanity\n> \t\t * of overriding \"git log\" with \"git show\" by having\n> \t\t * alias.log = show\n> \t\t */\n> -\t\tif (done_alias)\n> -\t\t\tbreak;\n> \t\tif (!handle_alias(argcp, argv))\n> \t\t\tbreak;\n> -\t\tdone_alias = 1;\n> +\t\tdone_alias++;\n> \t}\n>\n> +\tstring_list_clear(&cmd_list, 0);\n> +\n> \treturn done_alias;\n> }\n\n[In my just-sent\nhttps://public-inbox.org/git/87r2i6rbiy.fsf@evledraar.gmail.com/ I\nshould have said \"the v3 thread\"]\n\nThanks for working on this, comments:\n\nIf we don't have some test for these sort of aliasing loops that fails\nnow, we really should add that in a 1/2 and fix it in this patch in 2/2.\n\nThis error reporting is quite bad, consider:\n\n [alias]\n foo = bar\n bar = baz\n baz = foo\n\nWe then say:\n\n $ ./git --exec-path=$PWD foo\n fatal: loop alias: bar is called twice\n\nThat makes sense from an implementaion perspective, i.e. we lookup \"bar\"\ntwice. But let's do better. If I have aliase like:\n\n a = b\n b = c\n c = d\n d = e\n e = c\n\nIt should be telling me that my \"e\" expansion looped back to the \"c = d\"\nexpansion. Here's a patch to implement that, feel free to either squash\nit in with my Signed-Off-By, or tacked onto a v4 version of this,\nwhichever you think makes sense:\n\ndiff --git a/git.c b/git.c\nindex 64f5fbd572..38f1033e52 100644\n--- a/git.c\n+++ b/git.c\n@@ -692,8 +692,64 @@ static int run_argv(int *argcp, const char ***argv)\n \t\t/* .. then try the external ones */\n \t\texecv_dashed_external(*argv);\n\n-\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n-\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n+\t\tif (string_list_has_string(&cmd_list, *argv[0])) {\n+\t\t\tstruct strbuf sb = STRBUF_INIT;\n+\t\t\tint i, seen_at_idx = -1;\n+\n+\t\t\t/*\n+\t\t\t * Find the re-entry point for the alias\n+\t\t\t * loop. TODO: There really should be a\n+\t\t\t * \"return the index of the first matching\"\n+\t\t\t * helper in string-list.c.\n+\t\t\t */\n+\t\t\tfor (i = 0; i < cmd_list.nr; i++) {\n+\t\t\t\tif (!strcmp(*argv[0], cmd_list.items[i].string))\n+\t\t\t\t\tseen_at_idx = i;\n+\t\t\t}\n+\t\t\tassert(seen_at_idx != -1);\n+\n+\t\t\tfor (i = 1; i < cmd_list.nr; i++) {\n+\t\t\t\tif (i - 1 == seen_at_idx)\n+\t\t\t\t\t/*\n+\t\t\t\t\t * TRANSLATORS: This is a the\n+\t\t\t\t\t * re-enttry point in the list\n+\t\t\t\t\t * printed out by the \"alias\n+\t\t\t\t\t * loop\" message below.\n+\t\t\t\t\t */\n+\t\t\t\t\tstrbuf_addf(&sb, _(\" %d. %s = %s <== The re-entry point in the loop\\n\"),\n+\t\t\t\t\t\t i,\n+\t\t\t\t\t\t cmd_list.items[i - 1].string,\n+\t\t\t\t\t\t cmd_list.items[i].string);\n+\t\t\t\telse\n+\t\t\t\t\t/*\n+\t\t\t\t\t * TRANSLATORS: This is a\n+\t\t\t\t\t * single item in the list\n+\t\t\t\t\t * printed out by the \"alias\n+\t\t\t\t\t * loop\" message below.\n+\t\t\t\t\t */\n+\t\t\t\t\tstrbuf_addf(&sb, _(\" %d. %s = %s\\n\"),\n+\t\t\t\t\t\t i,\n+\t\t\t\t\t\t cmd_list.items[i - 1].string,\n+\t\t\t\t\t\t cmd_list.items[i].string);\n+\t\t\t}\n+\t\t\t/*\n+\t\t\t * TRANSLATORS: This is the last item in the\n+\t\t\t * list printed out by the \"alias loop\"\n+\t\t\t * message below.\n+\t\t\t */\n+\t\t\tstrbuf_addf(&sb, _(\" %d. %s = %s <== This is where the loop started!\"),\n+\t\t\t\t i,\n+\t\t\t\t cmd_list.items[i - 1].string,\n+\t\t\t\t *argv[0]);\n+\t\t\t/*\n+\t\t\t * TRANSLATORS: The %s here at the end is\n+\t\t\t * going to be a list of aliases as formatted\n+\t\t\t * by the messages whose comments mention\n+\t\t\t * \"alias loop\" above.\n+\t\t\t */\n+\t\t\tdie(_(\"alias loop: When expanding the alias '%s' we ran into a loop:\\n%s\"),\n+\t\t\t cmd_list.items[0].string, sb.buf);\n+\t\t}\n\n \t\tstring_list_append(&cmd_list, *argv[0]);\n\nNow we'll print errors like:\n\n $ ./git --exec-path=$PWD a\n fatal: alias loop: When expanding the alias 'a' we ran into a loop:\n 1. a = b\n 2. b = c\n 3. c = d <== The re-entry point in the loop\n 4. d = e\n 5. e = c <== This is where the loop started!\n\nOr, in the much simpler case of foo = bar; bar = foo:\n\n $ ./git --exec-path=$PWD foo\n fatal: alias loop: When expanding the alias 'foo' we ran into a loop:\n 1. foo = bar <== The re-entry point in the loop\n 2. bar = foo <== This is where the loop started!\n\nI haven't tested this much, so maybe there's some edge cases I haven't\nthought of / bugs in this reporting code, but hey, that's what the tests\nI suggested are for :)\n\nIt's a lot more verbose, but I think it's worth it to produce better\nerror messages.\n"},{"id":"357531","messageId":"87o9dar9qc.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"cd9a3a74-fdd6-0fb5-ae22-41d552391478@gmx.de","subject":"Re: [RFC PATCH v2] Allow aliases that include other aliases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-06T14:17:31Z","receivedAt":"2018-09-06T14:17:37Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Sep 05 2018, Tim Schumacher wrote:\n\n> On 05.09.18 19:34, Jeff King wrote:\n>>\n>> It could also extend to ! aliases if we wanted (i.e., my '!git foo'\n>> example from earlier), but you'd have to carry the counter through the\n>> environment between processes.\n>\n> That is a question about \"shooting oneself in the foot\" again,\n> but I think trying to prevent that would require more changes\n> than I can make, and it is definitely out-of-scope for this\n> patch.\n\nI agree it could be done later, but it would be great if you could\nfollow-up with that. Right now if you do:\n\n a = !git b\n b = !git a\n\nYou end up with a fork bomb, and we don't guard against this, and if you\nhave mixed execution / internal aliasing, e.g.:\n\n a = b\n b = c\n c = d\n d = !git a\n\nThe loop detection doesn't kick in.\n\nIt should be easy to add detection for this on top. See what we do with\ngit_config_push_parameter() in git.c already, i.e. you'd add some\nsimliar env variable, set items in the string list delimited by\ne.g. whitespace, and then just pre-populate your string list with that\nif it's set, and re-set it & carry it forward.\n\nThen any combination of internal aliasing and custom commands will\nbenefit from loop detection.\n"},{"id":"357532","messageId":"20180906145708.GA1209@sigill.intra.peff.net","threadId":"49280","inReplyTo":"87pnxqrags.fsf@evledraar.gmail.com","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-06T14:57:09Z","receivedAt":"2018-09-06T14:57:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> If we don't have some test for these sort of aliasing loops that fails\n> now, we really should add that in a 1/2 and fix it in this patch in 2/2.\n\nYes, I'd agree that this is worth adding a test (especially if the\noutput routines get more complex).\n\n> That makes sense from an implementaion perspective, i.e. we lookup \"bar\"\n> twice. But let's do better. If I have aliase like:\n> \n> a = b\n> b = c\n> c = d\n> d = e\n> e = c\n> \n> It should be telling me that my \"e\" expansion looped back to the \"c = d\"\n> expansion. Here's a patch to implement that, feel free to either squash\n> it in with my Signed-Off-By, or tacked onto a v4 version of this,\n> whichever you think makes sense:\n\nI don't have a strong opinion on whether this is worth it, but I think\nyour implementation could be a little simpler:\n\n> diff --git a/git.c b/git.c\n> index 64f5fbd572..38f1033e52 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -692,8 +692,64 @@ static int run_argv(int *argcp, const char ***argv)\n> \t\t/* .. then try the external ones */\n> \t\texecv_dashed_external(*argv);\n> \n> -\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n> -\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n> +\t\tif (string_list_has_string(&cmd_list, *argv[0])) {\n> +\t\t\tstruct strbuf sb = STRBUF_INIT;\n> +\t\t\tint i, seen_at_idx = -1;\n> +\n> +\t\t\t/*\n> +\t\t\t * Find the re-entry point for the alias\n> +\t\t\t * loop. TODO: There really should be a\n> +\t\t\t * \"return the index of the first matching\"\n> +\t\t\t * helper in string-list.c.\n> +\t\t\t */\n> +\t\t\tfor (i = 0; i < cmd_list.nr; i++) {\n> +\t\t\t\tif (!strcmp(*argv[0], cmd_list.items[i].string))\n> +\t\t\t\t\tseen_at_idx = i;\n> +\t\t\t}\n> +\t\t\tassert(seen_at_idx != -1);\n\nThe string-list code doesn't generally deal in indices. You can use\nstring_list_find_insert_index(), but its return value is a little funky\nfor the existing case. You can also just do:\n\n struct string_list_item *seen;\n ...\n seen = string_list_lookup(&cmd_list, *argv[0]);\n if (seen) {\n\t/* we have a loop */\n\tint idx = seen - cmd_list.items;\n\nThat's a little intimate with the string-list implementation as an array\nof string_list, but it's already pretty standard to walk over and\ndereference that list (including in your patch). But also see below.\n\nSide note: there's actually a bigger problem with the original patch:\nthe string list is unsorted (because it uses string_list_append(), and\nwhich is why your linear walk works here). But string_list_has_string()\nassumes it is sorted. So I think we'd actually want to use\nunsorted_string_list_has_string() or unsorted_string_list_lookup().\n\n> +\t\t\tfor (i = 1; i < cmd_list.nr; i++) {\n> +\t\t\t\tif (i - 1 == seen_at_idx)\n> +\t\t\t\t\t/*\n> +\t\t\t\t\t * TRANSLATORS: This is a the\n> +\t\t\t\t\t * re-enttry point in the list\n> +\t\t\t\t\t * printed out by the \"alias\n> +\t\t\t\t\t * loop\" message below.\n> +\t\t\t\t\t */\n> +\t\t\t\t\tstrbuf_addf(&sb, _(\" %d. %s = %s <== The re-entry point in the loop\\n\"),\n> +\t\t\t\t\t\t i,\n> +\t\t\t\t\t\t cmd_list.items[i - 1].string,\n> +\t\t\t\t\t\t cmd_list.items[i].string);\n\nThis is always going to show the right-hand of the equals as the\nleft-hand on the next line. Would it be simpler to just show the list?\nLikewise, the last item in the list is always going to be \"where the\nloop started\". Do we need to say that?\n\nE.g., something like:\n\n seen = unsorted_string_list_lookup(&cmd_list, *argv[0]);\n if (seen) {\n for (i = 0; i < cmd_list.nr; i++) {\n\t\tstruct string_list *item = cmd_list.items[i];\n\n\t\tstrbuf_addf(&sb, \" %s\", item->string);\n\t\tif (item == seen)\n\t\t\tstrbuf_add(&sb, \" <==\");\n\t\tstrbuf_addch(&sb, '\\n');\n\t }\n\t /* We never added this to the list, but we were about to */\n\t strbuf_addch(\" %s\\n\", seen->string);\n\t die(...);\n }\n\nI guess it's not that far off of yours. Not using words to describe the\nloop entry and exit points avoids translation, which avoids notes to\ntranslators, which is most of what makes your patch long. ;)\n\n-Peff\n"},{"id":"357533","messageId":"20180906145942.GB1209@sigill.intra.peff.net","threadId":"49280","inReplyTo":"20180906101658.1865-1-timschumi@gmx.de","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-06T14:59:42Z","receivedAt":"2018-09-06T14:59:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:\n\n> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)\n> \t\t/* .. then try the external ones */\n> \t\texecv_dashed_external(*argv);\n> \n> -\t\t/* It could be an alias -- this works around the insanity\n> +\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n> +\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n\nI pointed this out in my response to Ævar, but I want to make sure it\ngets seen. This call assumes the list is sorted, but...\n\n> +\t\tstring_list_append(&cmd_list, *argv[0]);\n\nThis will create an unsorted list. You'd have to use\nstring_list_insert() here for a sorted list, or\nunsorted_string_list_has_string() in the earlier call.\n\nIt's unfortunate that string_list makes this so easy to get wrong.\n\n> +\n> +\t\t/*\n> +\t\t * It could be an alias -- this works around the insanity\n> \t\t * of overriding \"git log\" with \"git show\" by having\n> \t\t * alias.log = show\n> \t\t */\n> -\t\tif (done_alias)\n> -\t\t\tbreak;\n> \t\tif (!handle_alias(argcp, argv))\n> \t\t\tbreak;\n> -\t\tdone_alias = 1;\n> +\t\tdone_alias++;\n\nI don't think anybody cares about done_alias being an accurate count.\nShould we just leave this as-is?\n\n-Peff\n"},{"id":"357534","messageId":"87musur7ar.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"20180906145708.GA1209@sigill.intra.peff.net","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-06T15:10:04Z","receivedAt":"2018-09-06T15:10:10Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Sep 06 2018, Jeff King wrote:\n\n> On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> If we don't have some test for these sort of aliasing loops that fails\n>> now, we really should add that in a 1/2 and fix it in this patch in 2/2.\n>\n> Yes, I'd agree that this is worth adding a test (especially if the\n> output routines get more complex).\n>\n>> That makes sense from an implementaion perspective, i.e. we lookup \"bar\"\n>> twice. But let's do better. If I have aliase like:\n>>\n>> a = b\n>> b = c\n>> c = d\n>> d = e\n>> e = c\n>>\n>> It should be telling me that my \"e\" expansion looped back to the \"c = d\"\n>> expansion. Here's a patch to implement that, feel free to either squash\n>> it in with my Signed-Off-By, or tacked onto a v4 version of this,\n>> whichever you think makes sense:\n>\n> I don't have a strong opinion on whether this is worth it, but I think\n> your implementation could be a little simpler:\n>\n>> diff --git a/git.c b/git.c\n>> index 64f5fbd572..38f1033e52 100644\n>> --- a/git.c\n>> +++ b/git.c\n>> @@ -692,8 +692,64 @@ static int run_argv(int *argcp, const char ***argv)\n>> \t\t/* .. then try the external ones */\n>> \t\texecv_dashed_external(*argv);\n>>\n>> -\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n>> -\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n>> +\t\tif (string_list_has_string(&cmd_list, *argv[0])) {\n>> +\t\t\tstruct strbuf sb = STRBUF_INIT;\n>> +\t\t\tint i, seen_at_idx = -1;\n>> +\n>> +\t\t\t/*\n>> +\t\t\t * Find the re-entry point for the alias\n>> +\t\t\t * loop. TODO: There really should be a\n>> +\t\t\t * \"return the index of the first matching\"\n>> +\t\t\t * helper in string-list.c.\n>> +\t\t\t */\n>> +\t\t\tfor (i = 0; i < cmd_list.nr; i++) {\n>> +\t\t\t\tif (!strcmp(*argv[0], cmd_list.items[i].string))\n>> +\t\t\t\t\tseen_at_idx = i;\n>> +\t\t\t}\n>> +\t\t\tassert(seen_at_idx != -1);\n>\n> The string-list code doesn't generally deal in indices. You can use\n> string_list_find_insert_index(), but its return value is a little funky\n> for the existing case. You can also just do:\n>\n> struct string_list_item *seen;\n> ...\n> seen = string_list_lookup(&cmd_list, *argv[0]);\n> if (seen) {\n> \t/* we have a loop */\n> \tint idx = seen - cmd_list.items;\n>\n> That's a little intimate with the string-list implementation as an array\n> of string_list, but it's already pretty standard to walk over and\n> dereference that list (including in your patch). But also see below.\n>\n> Side note: there's actually a bigger problem with the original patch:\n> the string list is unsorted (because it uses string_list_append(), and\n> which is why your linear walk works here). But string_list_has_string()\n> assumes it is sorted. So I think we'd actually want to use\n> unsorted_string_list_has_string() or unsorted_string_list_lookup().\n>\n>> +\t\t\tfor (i = 1; i < cmd_list.nr; i++) {\n>> +\t\t\t\tif (i - 1 == seen_at_idx)\n>> +\t\t\t\t\t/*\n>> +\t\t\t\t\t * TRANSLATORS: This is a the\n>> +\t\t\t\t\t * re-enttry point in the list\n>> +\t\t\t\t\t * printed out by the \"alias\n>> +\t\t\t\t\t * loop\" message below.\n>> +\t\t\t\t\t */\n>> +\t\t\t\t\tstrbuf_addf(&sb, _(\" %d. %s = %s <== The re-entry point in the loop\\n\"),\n>> +\t\t\t\t\t\t i,\n>> +\t\t\t\t\t\t cmd_list.items[i - 1].string,\n>> +\t\t\t\t\t\t cmd_list.items[i].string);\n>\n> This is always going to show the right-hand of the equals as the\n> left-hand on the next line. Would it be simpler to just show the list?\n> Likewise, the last item in the list is always going to be \"where the\n> loop started\". Do we need to say that?\n\nYeah maybe that's overzealous. I figured in the spirit of clang & GCC\ncompiler messages these days there's no such thing as too dumbed down :)\n\n> E.g., something like:\n>\n> seen = unsorted_string_list_lookup(&cmd_list, *argv[0]);\n> if (seen) {\n> for (i = 0; i < cmd_list.nr; i++) {\n> \t\tstruct string_list *item = cmd_list.items[i];\n>\n> \t\tstrbuf_addf(&sb, \" %s\", item->string);\n> \t\tif (item == seen)\n> \t\t\tstrbuf_add(&sb, \" <==\");\n> \t\tstrbuf_addch(&sb, '\\n');\n> \t }\n> \t /* We never added this to the list, but we were about to */\n> \t strbuf_addch(\" %s\\n\", seen->string);\n> \t die(...);\n> }\n>\n> I guess it's not that far off of yours. Not using words to describe the\n> loop entry and exit points avoids translation, which avoids notes to\n> translators, which is most of what makes your patch long. ;)\n\nThis still needs translation for RTL languages. I.e. they'd want to\nprint out the equivalent of \"%s \" followed by \"==> %s \". We happen to\n(unfortunately) not carry such a language yet, but it's worth\nfuture-proofing output as we add it in case we get one.\n"},{"id":"357545","messageId":"20180906161817.GA12705@sigill.intra.peff.net","threadId":"49280","inReplyTo":"87musur7ar.fsf@evledraar.gmail.com","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-06T16:18:17Z","receivedAt":"2018-09-06T16:18:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 06, 2018 at 05:10:04PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > seen = unsorted_string_list_lookup(&cmd_list, *argv[0]);\n> > if (seen) {\n> > for (i = 0; i < cmd_list.nr; i++) {\n> > \t\tstruct string_list *item = cmd_list.items[i];\n> >\n> > \t\tstrbuf_addf(&sb, \" %s\", item->string);\n> > \t\tif (item == seen)\n> > \t\t\tstrbuf_add(&sb, \" <==\");\n> > \t\tstrbuf_addch(&sb, '\\n');\n> > \t }\n> > \t /* We never added this to the list, but we were about to */\n> > \t strbuf_addch(\" %s\\n\", seen->string);\n> > \t die(...);\n> > }\n> >\n> > I guess it's not that far off of yours. Not using words to describe the\n> > loop entry and exit points avoids translation, which avoids notes to\n> > translators, which is most of what makes your patch long. ;)\n> \n> This still needs translation for RTL languages. I.e. they'd want to\n> print out the equivalent of \"%s \" followed by \"==> %s \". We happen to\n> (unfortunately) not carry such a language yet, but it's worth\n> future-proofing output as we add it in case we get one.\n\nI'd have thought even in an RTL language that something like an \"I'm\npointing to this\" sign wouldn't matter (i.e., an LTR language person,\nI'd be fine with either \"==> %s\" or \"%s <==\"). But obviously I have no\nexperience in the matter, so I'd defer to people who read RTL (or at\nleast have handled i18n for it before).\n\n-Peff\n"},{"id":"357560","messageId":"xmqqy3cezcz5.fsf@gitster-ct.c.googlers.com","threadId":"49280","inReplyTo":"20180906145942.GB1209@sigill.intra.peff.net","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-06T18:40:14Z","receivedAt":"2018-09-06T18:40:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:\n>\n>> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)\n>> \t\t/* .. then try the external ones */\n>> \t\texecv_dashed_external(*argv);\n>> \n>> -\t\t/* It could be an alias -- this works around the insanity\n>> +\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n>> +\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n>\n> I pointed this out in my response to Ævar, but I want to make sure it\n> gets seen. This call assumes the list is sorted, but...\n>\n>> +\t\tstring_list_append(&cmd_list, *argv[0]);\n>\n> This will create an unsorted list. You'd have to use\n> string_list_insert() here for a sorted list, or\n> unsorted_string_list_has_string() in the earlier call.\n\nCorrect.\n\nAlso, normal users who have never seen this loop that implements\nalias expansion would not have a clue when they see \"called twice\".\n\nI actually think the caller should also pass cmd to run_argv() and\nthen we should use it (and not argv[]) in this die() message. When\nthe original command was foo that is aliased to bar, which in turn\nis aliased to baz, which in turn is aliased to bar, especially that\n\"git foo\" invocation was in a random script written six weeks ago by\nthe user, it would be a lot more helpful to see \n\n \"alias loop detected: expansion of 'git foo' does not terminate\"\n\nthan\n\n \"loop alias: bar is called twice\".\n\ngiven that 'bar' is not something the user called, or written in the\nscript she wrote six weeks ago.\n\n> It's unfortunate that string_list makes this so easy to get wrong.\n>\n>> +\n>> +\t\t/*\n>> +\t\t * It could be an alias -- this works around the insanity\n>> \t\t * of overriding \"git log\" with \"git show\" by having\n>> \t\t * alias.log = show\n>> \t\t */\n>> -\t\tif (done_alias)\n>> -\t\t\tbreak;\n>> \t\tif (!handle_alias(argcp, argv))\n>> \t\t\tbreak;\n>> -\t\tdone_alias = 1;\n>> +\t\tdone_alias++;\n>\n> I don't think anybody cares about done_alias being an accurate count.\n> Should we just leave this as-is?\n\nGood point. The only caller treats it as a bool (i.e. \"should the\nfailure be reported as failure to expand an alias cmd which resulted\nin (updated) argv[0] that is not a git command?\").\n"},{"id":"357562","messageId":"20180906190511.GA23884@sigill.intra.peff.net","threadId":"49280","inReplyTo":"xmqqy3cezcz5.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-06T19:05:12Z","receivedAt":"2018-09-06T19:05:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 06, 2018 at 11:40:14AM -0700, Junio C Hamano wrote:\n\n> Also, normal users who have never seen this loop that implements\n> alias expansion would not have a clue when they see \"called twice\".\n> \n> I actually think the caller should also pass cmd to run_argv() and\n> then we should use it (and not argv[]) in this die() message. When\n> the original command was foo that is aliased to bar, which in turn\n> is aliased to baz, which in turn is aliased to bar, especially that\n> \"git foo\" invocation was in a random script written six weeks ago by\n> the user, it would be a lot more helpful to see \n> \n> \"alias loop detected: expansion of 'git foo' does not terminate\"\n> \n> than\n> \n> \"loop alias: bar is called twice\".\n> \n> given that 'bar' is not something the user called, or written in the\n> script she wrote six weeks ago.\n\nGood point. I think Ævar's \"print the whole list\" solves that, because\nitems[0] is that first element. But I agree the fundamental message\nshould be \"loop in 'git foo'\".\n\n-Peff\n"},{"id":"357563","messageId":"dea58ad8-4e2a-955a-8dc6-b93e9592398c@gmx.de","threadId":"49280","inReplyTo":"20180906145708.GA1209@sigill.intra.peff.net","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-06T19:05:50Z","receivedAt":"2018-09-06T19:06:02Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"On 06.09.18 16:57, Jeff King wrote:\n> On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> \n>> If we don't have some test for these sort of aliasing loops that fails\n>> now, we really should add that in a 1/2 and fix it in this patch in 2/2.\n> \n> Yes, I'd agree that this is worth adding a test (especially if the\n> output routines get more complex).\n\nI'll try to come up with a few tests (or one at this point, as we only have\na solution for internal aliases so far) and put them as 1/2. However, I don't know\nwhat file I should put those tests into. t0001-init and t1300-config both seem\nto test aliases, but I'm unsure if the new tests should go into one of those\nfiles or a completely new one that is dedicated to aliases.\n\n> \n>> That makes sense from an implementaion perspective, i.e. we lookup \"bar\"\n>> twice. But let's do better. If I have aliase like:\n>>\n>> a = b\n>> b = c\n>> c = d\n>> d = e\n>> e = c\n>>\n>> It should be telling me that my \"e\" expansion looped back to the \"c = d\"\n>> expansion. Here's a patch to implement that, feel free to either squash\n>> it in with my Signed-Off-By, or tacked onto a v4 version of this,\n>> whichever you think makes sense:\n> \n> I don't have a strong opinion on whether this is worth it, but I think\n> your implementation could be a little simpler:\n> \n>> diff --git a/git.c b/git.c\n>> index 64f5fbd572..38f1033e52 100644\n>> --- a/git.c\n>> +++ b/git.c\n>> @@ -692,8 +692,64 @@ static int run_argv(int *argcp, const char ***argv)\n>> \t\t/* .. then try the external ones */\n>> \t\texecv_dashed_external(*argv);\n>>\n>> -\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n>> -\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n>> +\t\tif (string_list_has_string(&cmd_list, *argv[0])) {\n>> +\t\t\tstruct strbuf sb = STRBUF_INIT;\n>> +\t\t\tint i, seen_at_idx = -1;\n>> +\n>> +\t\t\t/*\n>> +\t\t\t * Find the re-entry point for the alias\n>> +\t\t\t * loop. TODO: There really should be a\n>> +\t\t\t * \"return the index of the first matching\"\n>> +\t\t\t * helper in string-list.c.\n>> +\t\t\t */\n>> +\t\t\tfor (i = 0; i < cmd_list.nr; i++) {\n>> +\t\t\t\tif (!strcmp(*argv[0], cmd_list.items[i].string))\n>> +\t\t\t\t\tseen_at_idx = i;\n>> +\t\t\t}\n>> +\t\t\tassert(seen_at_idx != -1);\n> \n> The string-list code doesn't generally deal in indices. You can use\n> string_list_find_insert_index(), but its return value is a little funky\n> for the existing case. You can also just do:\n> \n> struct string_list_item *seen;\n> ...\n> seen = string_list_lookup(&cmd_list, *argv[0]);\n> if (seen) {\n> \t/* we have a loop */\n> \tint idx = seen - cmd_list.items;\n> \n> That's a little intimate with the string-list implementation as an array\n> of string_list, but it's already pretty standard to walk over and\n> dereference that list (including in your patch). But also see below.\n> \n> Side note: there's actually a bigger problem with the original patch:\n> the string list is unsorted (because it uses string_list_append(), and\n> which is why your linear walk works here). But string_list_has_string()\n> assumes it is sorted. So I think we'd actually want to use\n> unsorted_string_list_has_string() or unsorted_string_list_lookup().\n\nI'll update v4 to use use unsorted_string_list_has_string().\n> \n>> +\t\t\tfor (i = 1; i < cmd_list.nr; i++) {\n>> +\t\t\t\tif (i - 1 == seen_at_idx)\n>> +\t\t\t\t\t/*\n>> +\t\t\t\t\t * TRANSLATORS: This is a the\n>> +\t\t\t\t\t * re-enttry point in the list\n>> +\t\t\t\t\t * printed out by the \"alias\n>> +\t\t\t\t\t * loop\" message below.\n>> +\t\t\t\t\t */\n>> +\t\t\t\t\tstrbuf_addf(&sb, _(\" %d. %s = %s <== The re-entry point in the loop\\n\"),\n>> +\t\t\t\t\t\t i,\n>> +\t\t\t\t\t\t cmd_list.items[i - 1].string,\n>> +\t\t\t\t\t\t cmd_list.items[i].string);\n> \n> This is always going to show the right-hand of the equals as the\n> left-hand on the next line. Would it be simpler to just show the list?\n> Likewise, the last item in the list is always going to be \"where the\n> loop started\". Do we need to say that?\n> \n> E.g., something like:\n> \n> seen = unsorted_string_list_lookup(&cmd_list, *argv[0]);\n> if (seen) {\n> for (i = 0; i < cmd_list.nr; i++) {\n> \t\tstruct string_list *item = cmd_list.items[i];\n> \n> \t\tstrbuf_addf(&sb, \" %s\", item->string);\n> \t\tif (item == seen)\n> \t\t\tstrbuf_add(&sb, \" <==\");\n> \t\tstrbuf_addch(&sb, '\\n');\n> \t }\n> \t /* We never added this to the list, but we were about to */\n> \t strbuf_addch(\" %s\\n\", seen->string);\n> \t die(...);\n> }\n> \n> I guess it's not that far off of yours. Not using words to describe the\n> loop entry and exit points avoids translation, which avoids notes to\n> translators, which is most of what makes your patch long. ;)\n> \n> -Peff\n> \n\nI'll tinker around with both code snippets, we'll see which one is\nmore convenient for the user.\n\nThanks to all of you for the input!\n\nTim\n"},{"id":"357565","messageId":"20180906191704.GA26575@sigill.intra.peff.net","threadId":"49280","inReplyTo":"dea58ad8-4e2a-955a-8dc6-b93e9592398c@gmx.de","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-06T19:17:05Z","receivedAt":"2018-09-06T19:17:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 06, 2018 at 09:05:50PM +0200, Tim Schumacher wrote:\n\n> On 06.09.18 16:57, Jeff King wrote:\n> > On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> > \n> > > If we don't have some test for these sort of aliasing loops that fails\n> > > now, we really should add that in a 1/2 and fix it in this patch in 2/2.\n> > \n> > Yes, I'd agree that this is worth adding a test (especially if the\n> > output routines get more complex).\n> \n> I'll try to come up with a few tests (or one at this point, as we only have\n> a solution for internal aliases so far) and put them as 1/2. However, I don't know\n> what file I should put those tests into. t0001-init and t1300-config both seem\n> to test aliases, but I'm unsure if the new tests should go into one of those\n> files or a completely new one that is dedicated to aliases.\n\nYeah, I don't think there's a good place right now. It probably make\nsense to start a new one (t0014-alias, maybe? This seems like a basic\nfunctionality that should come early in the suite).\n\n-Peff\n"},{"id":"357567","messageId":"4f814d67-c384-6d1e-a988-97cc25e32475@gmx.de","threadId":"49280","inReplyTo":"xmqqy3cezcz5.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v3] Allow aliases that include other aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-06T19:31:10Z","receivedAt":"2018-09-06T19:31:20Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"On 06.09.18 20:40, Junio C Hamano wrote:\n> Jeff King writes:\n> \n>> On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:\n>>\n>>> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)\n>>> \t\t/* .. then try the external ones */\n>>> \t\texecv_dashed_external(*argv);\n>>> \n>>> -\t\t/* It could be an alias -- this works around the insanity\n>>> +\t\tif (string_list_has_string(&cmd_list, *argv[0]))\n>>> +\t\t\tdie(_(\"loop alias: %s is called twice\"), *argv[0]);\n>>\n>> I pointed this out in my response to Ævar, but I want to make sure it\n>> gets seen. This call assumes the list is sorted, but...\n>>\n>>> +\t\tstring_list_append(&cmd_list, *argv[0]);\n>>\n>> This will create an unsorted list. You'd have to use\n>> string_list_insert() here for a sorted list, or\n>> unsorted_string_list_has_string() in the earlier call.\n> \n> Correct.\n> \n> Also, normal users who have never seen this loop that implements\n> alias expansion would not have a clue when they see \"called twice\".\n> \n> I actually think the caller should also pass cmd to run_argv() and\n> then we should use it (and not argv[]) in this die() message.\n\nCould we just save the first element of the original argv for that\npurpose? Or alternatively, use the first stored element in the\ncommand list?\n\n> When\n> the original command was foo that is aliased to bar, which in turn\n> is aliased to baz, which in turn is aliased to bar, especially that\n> \"git foo\" invocation was in a random script written six weeks ago by\n> the user, it would be a lot more helpful to see\n> \n> \"alias loop detected: expansion of 'git foo' does not terminate\"\n> \n> than\n> \n> \"loop alias: bar is called twice\".\n> \n> given that 'bar' is not something the user called, or written in the\n> script she wrote six weeks ago.\n\nIndeed, printing the command that the user called is a better message\nthan the command that is the entry-point of the loop. I'll change it\nin v4.\n\n> \n>> It's unfortunate that string_list makes this so easy to get wrong.\n>>\n>>> +\n>>> +\t\t/*\n>>> +\t\t * It could be an alias -- this works around the insanity\n>>> \t\t * of overriding \"git log\" with \"git show\" by having\n>>> \t\t * alias.log = show\n>>> \t\t */\n>>> -\t\tif (done_alias)\n>>> -\t\t\tbreak;\n>>> \t\tif (!handle_alias(argcp, argv))\n>>> \t\t\tbreak;\n>>> -\t\tdone_alias = 1;\n>>> +\t\tdone_alias++;\n>>\n>> I don't think anybody cares about done_alias being an accurate count.\n>> Should we just leave this as-is?\n> \n> Good point. The only caller treats it as a bool (i.e. \"should the\n> failure be reported as failure to expand an alias cmd which resulted\n> in (updated) argv[0] that is not a git command?\").\n> \n\nAs the string-list has its own counter, I guess the done_alias variable\ncan be reverted to a simple 0/1 value.\n"},{"id":"357663","messageId":"20180907224430.23859-2-timschumi@gmx.de","threadId":"49280","inReplyTo":"20180907224430.23859-1-timschumi@gmx.de","subject":"[RFC PATCH v4 2/3] Show the call history when an alias is looping","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-07T22:44:29Z","receivedAt":"2018-09-07T22:44:45Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"Just printing the command that the user entered is not particularly\nhelpful when trying to find the alias that causes the loop.\n\nPrint the history of substituted commands to help the user find the\noffending alias. Mark the entrypoint of the loop with \"<==\" and the\nlast command (which looped back to the entrypoint) with \"==>\".\n\nSigned-off-by: Tim Schumacher \n---\n\nI now went with Peff's suggested code and I added in an arrow that points\naway from the last command (which caused the loop). A \"full\" arrow (i.e.\nstarts at the last command, goes upwards and ends at the entrypoint) would\nbe more obvious/better, but adding much more code just for having a\nvertical line wasn't worth it for me.\n\n git.c | 17 +++++++++++++++--\n 1 file changed, 15 insertions(+), 2 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex 15727c17f..a20eb4fa1 100644\n--- a/git.c\n+++ b/git.c\n@@ -675,6 +675,7 @@ static int run_argv(int *argcp, const char ***argv)\n {\n \tint done_alias = 0;\n \tstruct string_list cmd_list = STRING_LIST_INIT_NODUP;\n+\tstruct string_list_item *seen;\n \n \twhile (1) {\n \t\t/*\n@@ -692,9 +693,21 @@ static int run_argv(int *argcp, const char ***argv)\n \t\t/* .. then try the external ones */\n \t\texecv_dashed_external(*argv);\n \n-\t\tif (unsorted_string_list_has_string(&cmd_list, *argv[0])) {\n+\t\tseen = unsorted_string_list_lookup(&cmd_list, *argv[0]);\n+\t\tif (seen) {\n+\t\t\tint i;\n+\t\t\tstruct strbuf sb = STRBUF_INIT;\n+\t\t\tfor (i = 0; i < cmd_list.nr; i++) {\n+\t\t\t\tstruct string_list_item *item = &cmd_list.items[i];\n+\n+\t\t\t\tstrbuf_addf(&sb, \"\\n %s\", item->string);\n+\t\t\t\tif (item == seen)\n+\t\t\t\t\tstrbuf_addstr(&sb, \" <==\");\n+\t\t\t\telse if (i == cmd_list.nr - 1)\n+\t\t\t\t\tstrbuf_addstr(&sb, \" ==>\");\n+\t\t\t}\n \t\t\tdie(_(\"alias loop detected: expansion of '%s' does\"\n-\t\t\t \" not terminate\"), cmd_list.items[0].string);\n+\t\t\t \" not terminate:%s\"), cmd_list.items[0].string, sb.buf);\n \t\t}\n \n \t\tstring_list_append(&cmd_list, *argv[0]);\n-- \n2.19.0.rc2.1.g4c98b8d69.dirty\n\n"},{"id":"357664","messageId":"20180907224430.23859-1-timschumi@gmx.de","threadId":"49280","inReplyTo":"20180905085427.4099-1-timschumi@gmx.de","subject":"[RFC PATCH v4 1/3] Add support for nested aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-07T22:44:28Z","receivedAt":"2018-09-07T22:44:46Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"Aliases can only contain non-alias git commands and their\narguments, not other user-defined aliases. Resolving further\n(nested) aliases is prevented by breaking the loop after the\nfirst alias was processed. Git then fails with a command-not-found\nerror.\n\nAllow resolving nested aliases by not breaking the loop in\nrun_argv() after the first alias was processed. Instead, continue\nthe loop until `handle_alias()` fails, which means that there are\nno further aliases that can be processed. Prevent looping aliases\nby storing substituted commands in `cmd_list` and checking if\na command has been substituted previously.\n\nWhile we're at it, fix a styling issue just below the added code.\n\nSigned-off-by: Tim Schumacher \n---\nChanges since v3:\n - Print the command that the user entered instead of the command\n which caused the loop (and a nicer, more explanatory error message)\n - Use unsorted_string_list_has_string() instead of the sorted version\n - Fix a code style issue just below the modified code\n - done_alias is a simple boolean again (instead of a counter)\n\n git.c | 15 ++++++++++++---\n 1 file changed, 12 insertions(+), 3 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex c27c38738..15727c17f 100644\n--- a/git.c\n+++ b/git.c\n@@ -674,6 +674,7 @@ static void execv_dashed_external(const char **argv)\n static int run_argv(int *argcp, const char ***argv)\n {\n \tint done_alias = 0;\n+\tstruct string_list cmd_list = STRING_LIST_INIT_NODUP;\n \n \twhile (1) {\n \t\t/*\n@@ -691,17 +692,25 @@ static int run_argv(int *argcp, const char ***argv)\n \t\t/* .. then try the external ones */\n \t\texecv_dashed_external(*argv);\n \n-\t\t/* It could be an alias -- this works around the insanity\n+\t\tif (unsorted_string_list_has_string(&cmd_list, *argv[0])) {\n+\t\t\tdie(_(\"alias loop detected: expansion of '%s' does\"\n+\t\t\t \" not terminate\"), cmd_list.items[0].string);\n+\t\t}\n+\n+\t\tstring_list_append(&cmd_list, *argv[0]);\n+\n+\t\t/*\n+\t\t * It could be an alias -- this works around the insanity\n \t\t * of overriding \"git log\" with \"git show\" by having\n \t\t * alias.log = show\n \t\t */\n-\t\tif (done_alias)\n-\t\t\tbreak;\n \t\tif (!handle_alias(argcp, argv))\n \t\t\tbreak;\n \t\tdone_alias = 1;\n \t}\n \n+\tstring_list_clear(&cmd_list, 0);\n+\n \treturn done_alias;\n }\n \n-- \n2.19.0.rc2.1.g4c98b8d69.dirty\n\n"},{"id":"357665","messageId":"20180907224430.23859-3-timschumi@gmx.de","threadId":"49280","inReplyTo":"20180907224430.23859-1-timschumi@gmx.de","subject":"[RFC PATCH v4 3/3] t0014: Introduce alias testing suite","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-07T22:44:30Z","receivedAt":"2018-09-07T22:44:47Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"Introduce a testing suite that is dedicated to aliases.\nFor now, check only if nested aliases work and if looping\naliases are detected successfully.\n\nThe looping aliases check for mixed execution is there but\nexpected to fail because there is no check in place yet.\n\nSigned-off-by: Tim Schumacher \n---\n\nThose are the tests that I've come up with. It consists of tests\nfor nested aliases and looping aliases, both with internal calls\nand external calls.\n\nUnfortunately I don't have a fix for the last one yet, so I\nmarked it as expect_failure. The problem is that the test suite\nis waiting a full minute until it aborts the running command\n(which I guess should not take that long, as it blocks the whole\ntest suite for that span of time).\n\nShould I try to decrease the timeout or should I remove that\ntest completely until I manage to get external calls fixed?\n\nAs a last thing, is there any better way to use single quotes\nthan to write '\"'\"'? It isn't that bad, but it is hard to read,\nespecially for bash newcomers.\n\n t/t0014-alias.sh | 38 ++++++++++++++++++++++++++++++++++++++\n 1 file changed, 38 insertions(+)\n create mode 100755 t/t0014-alias.sh\n\ndiff --git a/t/t0014-alias.sh b/t/t0014-alias.sh\nnew file mode 100755\nindex 000000000..6c1e34694\n--- /dev/null\n+++ b/t/t0014-alias.sh\n@@ -0,0 +1,38 @@\n+#!/bin/sh\n+\n+test_description='git command aliasing'\n+\n+. ./test-lib.sh\n+\n+test_expect_success 'setup environment' '\n+\tgit init\n+'\n+\n+test_expect_success 'nested aliases - internal execution' '\n+\tgit config alias.nested-internal-1 nested-internal-2 &&\n+\tgit config alias.nested-internal-2 status\n+'\n+\n+test_expect_success 'nested aliases - mixed execution' '\n+\tgit config alias.nested-external-1 \"!git nested-external-2\" &&\n+\tgit config alias.nested-external-2 status\n+'\n+\n+test_expect_success 'looping aliases - internal execution' '\n+\tgit config alias.loop-internal-1 loop-internal-2 &&\n+\tgit config alias.loop-internal-2 loop-internal-3 &&\n+\tgit config alias.loop-internal-3 loop-internal-2 &&\n+\ttest_must_fail git loop-internal-1 2>output &&\n+\tgrep -q \"fatal: alias loop detected: expansion of '\"'\"'loop-internal-1'\"'\"' does not terminate\" output &&\n+\trm output\n+'\n+\n+test_expect_failure 'looping aliases - mixed execution' '\n+\tgit config alias.loop-mixed-1 loop-mixed-2 &&\n+\tgit config alias.loop-mixed-2 \"!git loop-mixed-1\" &&\n+\ttest_must_fail git loop-mixed-1 2>output &&\n+\tgrep -q \"fatal: alias loop detected: expansion of '\"'\"'loop-mixed-1'\"'\"' does not terminate\" output &&\n+\trm output\n+'\n+\n+test_done\n-- \n2.19.0.rc2.1.g4c98b8d69.dirty\n\n"},{"id":"357668","messageId":"CAPig+cR1JpZqxBAsR+6_WjLwofnU8siB9VXYdUkXY2P-xQnsuQ@mail.gmail.com","threadId":"49280","inReplyTo":"20180907224430.23859-3-timschumi@gmx.de","subject":"Re: [RFC PATCH v4 3/3] t0014: Introduce alias testing suite","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-09-07T23:38:39Z","receivedAt":"2018-09-07T23:38:54Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Sep 7, 2018 at 6:44 PM Tim Schumacher wrote:\n> Introduce a testing suite that is dedicated to aliases.\n> For now, check only if nested aliases work and if looping\n> aliases are detected successfully.\n>\n> The looping aliases check for mixed execution is there but\n> expected to fail because there is no check in place yet.\n>\n> Signed-off-by: Tim Schumacher \n> ---\n> Unfortunately I don't have a fix for the last one yet, so I\n> marked it as expect_failure. The problem is that the test suite\n> is waiting a full minute until it aborts the running command\n> (which I guess should not take that long, as it blocks the whole\n> test suite for that span of time).\n>\n> Should I try to decrease the timeout or should I remove that\n> test completely until I manage to get external calls fixed?\n\nPerhaps just comment out that test for now and add a comment above it\nexplaining why it's commented out.\n\n> As a last thing, is there any better way to use single quotes\n> than to write '\"'\"'? It isn't that bad, but it is hard to read,\n> especially for bash newcomers.\n\nYou should backslash-escape the quotes (\"foo \\'bar\\' baz\"), however,\nin this case, it would make sense to use regex's with 'grep' to check\nthat you got the expected error message rather than reproducing the\nmessage literally here in the script.\n\nMore below.\n\n> diff --git a/t/t0014-alias.sh b/t/t0014-alias.sh\n> @@ -0,0 +1,38 @@\n> +#!/bin/sh\n> +\n> +test_description='git command aliasing'\n> +\n> +. ./test-lib.sh\n> +\n> +test_expect_success 'setup environment' '\n> + git init\n> +'\n\n\"git init\" is invoked automatically by the test framework, so no need\nfor this test. You can drop it.\n\n> +test_expect_success 'nested aliases - internal execution' '\n> + git config alias.nested-internal-1 nested-internal-2 &&\n> + git config alias.nested-internal-2 status\n> +'\n\nThis isn't actually testing anything, is it? It's setting up the\naliases but never actually invoking them. I would have expected the\nnext line to actually run a command (\"git nested-internal-1\") and the\nline after that to check that you got the expected output (whatever\n\"git status\" would emit). Output from \"git status\" isn't necessarily\nthe easiest to test, though, so perhaps pick a different Git command\nfor testing (something for which the result can be very easily checked\n-- maybe \"git rm\" or such).\n\n> +test_expect_success 'nested aliases - mixed execution' '\n> + git config alias.nested-external-1 \"!git nested-external-2\" &&\n> + git config alias.nested-external-2 status\n> +'\n\nSame observation.\n\n> +test_expect_success 'looping aliases - internal execution' '\n> + git config alias.loop-internal-1 loop-internal-2 &&\n> + git config alias.loop-internal-2 loop-internal-3 &&\n> + git config alias.loop-internal-3 loop-internal-2 &&\n> + test_must_fail git loop-internal-1 2>output &&\n> + grep -q \"fatal: alias loop detected: expansion of '\"'\"'loop-internal-1'\"'\"' does not terminate\" output &&\n\nDon't bother using -q with 'grep'. Output is hidden already by the\ntest framework in normal mode, and not hidden when running in verbose\nmode. And, the output of 'grep' might be helpful when debugging the\ntest if something goes wrong.\n\nAs noted above, you can use regex to match the expected error rather\nthan exactly duplicating the text of the message.\n\nFinally, use 'test_i18ngrep' instead of 'grep' in order to play nice\nwith localization.\n\n> + rm output\n\nTests don't normally bother cleaning up their output files like this\nsince such output can be helpful when debugging the test if something\ngoes wrong. (You'd want to use test_when_finished to cleanup anyhow,\nbut you don't need it in this case.)\n\n> +'\n"},{"id":"357689","messageId":"CACsJy8BnHgaphwy3beCCquFjU=SZebR2GvDCkFgh1_snxDBTRQ@mail.gmail.com","threadId":"49280","inReplyTo":"20180907224430.23859-1-timschumi@gmx.de","subject":"Re: [RFC PATCH v4 1/3] Add support for nested aliases","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-09-08T13:28:05Z","receivedAt":"2018-09-08T13:28:33Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:\n> + /*\n> + * It could be an alias -- this works around the insanity\n> * of overriding \"git log\" with \"git show\" by having\n> * alias.log = show\n> */\n\nI think this comment block is about the next two lines you just\ndeleted. So delete it to instead of fixing style.\n\n> - if (done_alias)\n> - break;\n> if (!handle_alias(argcp, argv))\n> break;\n> done_alias = 1;\n> }\n-- \nDuy\n"},{"id":"357690","messageId":"CACsJy8C+VPGyu1D6yeFU3eqzwusv_Q=tobZgvXOtZ=5gYak5dg@mail.gmail.com","threadId":"49280","inReplyTo":"20180907224430.23859-2-timschumi@gmx.de","subject":"Re: [RFC PATCH v4 2/3] Show the call history when an alias is looping","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-09-08T13:34:34Z","receivedAt":"2018-09-08T13:35:02Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:\n>\n> Just printing the command that the user entered is not particularly\n> helpful when trying to find the alias that causes the loop.\n>\n> Print the history of substituted commands to help the user find the\n> offending alias. Mark the entrypoint of the loop with \"<==\" and the\n> last command (which looped back to the entrypoint) with \"==>\".\n\nAn even simpler way to give this information is simply suggest the\nuser tries again with GIT_TRACE=1. All alias expansion is shown there\nand we teach the user about GIT_TRACE. But your approach is probably\nmore user friendly.\n-- \nDuy\n"},{"id":"357700","messageId":"20180908162908.GC9016@sigill.intra.peff.net","threadId":"49280","inReplyTo":"CACsJy8C+VPGyu1D6yeFU3eqzwusv_Q=tobZgvXOtZ=5gYak5dg@mail.gmail.com","subject":"Re: [RFC PATCH v4 2/3] Show the call history when an alias is looping","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-08T16:29:09Z","receivedAt":"2018-09-08T16:29:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 08, 2018 at 03:34:34PM +0200, Duy Nguyen wrote:\n\n> On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:\n> >\n> > Just printing the command that the user entered is not particularly\n> > helpful when trying to find the alias that causes the loop.\n> >\n> > Print the history of substituted commands to help the user find the\n> > offending alias. Mark the entrypoint of the loop with \"<==\" and the\n> > last command (which looped back to the entrypoint) with \"==>\".\n> \n> An even simpler way to give this information is simply suggest the\n> user tries again with GIT_TRACE=1. All alias expansion is shown there\n> and we teach the user about GIT_TRACE. But your approach is probably\n> more user friendly.\n\nGood point. I'm OK with the amount of code here for the nicer message\n(but would be happy either way).\n\nIf we were going to track cross-process loops like Ævar suggested, I\nthink I'd rather go with a simple counter and just ask the user to run\nwith GIT_TRACE when it exceeds some maximum sanity value. For two\nreasons:\n\n 1. Passing a counter through the environment is way simpler than\n an arbitrarily-sized list.\n\n 2. When you get into multiple processes, there's potentially more\n going on than just Git commands. You might have a git command which\n runs a hook which runs a third party script which runs a git\n command, which runs a hook, and so on. That full dump is going to\n be more useful.\n\n-Peff\n"},{"id":"358169","messageId":"bd63006e-18a7-1c41-252c-cf47a65ba7cb@gmx.de","threadId":"49280","inReplyTo":"CAPig+cR1JpZqxBAsR+6_WjLwofnU8siB9VXYdUkXY2P-xQnsuQ@mail.gmail.com","subject":"Re: [RFC PATCH v4 3/3] t0014: Introduce alias testing suite","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-14T23:12:17Z","receivedAt":"2018-09-14T23:12:29Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"On 08.09.18 01:38, Eric Sunshine wrote:\n> On Fri, Sep 7, 2018 at 6:44 PM Tim Schumacher wrote:\n>> Introduce a testing suite that is dedicated to aliases.\n>> For now, check only if nested aliases work and if looping\n>> aliases are detected successfully.\n>>\n>> The looping aliases check for mixed execution is there but\n>> expected to fail because there is no check in place yet.\n>>\n>> Signed-off-by: Tim Schumacher \n>> ---\n>> Unfortunately I don't have a fix for the last one yet, so I\n>> marked it as expect_failure. The problem is that the test suite\n>> is waiting a full minute until it aborts the running command\n>> (which I guess should not take that long, as it blocks the whole\n>> test suite for that span of time).\n>>\n>> Should I try to decrease the timeout or should I remove that\n>> test completely until I manage to get external calls fixed?\n> \n> Perhaps just comment out that test for now and add a comment above it\n> explaining why it's commented out.\n\nThat will probably be the easiest thing to do. I commented it out for\nnow, added a short information about that to the code itself and a longer\nexplanation to the commit message.\n\n> \n>> As a last thing, is there any better way to use single quotes\n>> than to write '\"'\"'? It isn't that bad, but it is hard to read,\n>> especially for bash newcomers.\n> \n> You should backslash-escape the quotes (\"foo \\'bar\\' baz\"), however,\n> in this case, it would make sense to use regex's with 'grep' to check\n> that you got the expected error message rather than reproducing the\n> message literally here in the script.\n\nBackslash-escaping didn't work, that resulted in some parsing error.\nI'm using i18ngrep now to search for the part of a message, which\neliminates the need for quotes completely.\n\n> \n> More below.\n> \n>> diff --git a/t/t0014-alias.sh b/t/t0014-alias.sh\n>> @@ -0,0 +1,38 @@\n>> +#!/bin/sh\n>> +\n>> +test_description='git command aliasing'\n>> +\n>> +. ./test-lib.sh\n>> +\n>> +test_expect_success 'setup environment' '\n>> + git init\n>> +'\n> \n> \"git init\" is invoked automatically by the test framework, so no need\n> for this test. You can drop it.\n> \n>> +test_expect_success 'nested aliases - internal execution' '\n>> + git config alias.nested-internal-1 nested-internal-2 &&\n>> + git config alias.nested-internal-2 status\n>> +'\n> \n> This isn't actually testing anything, is it? It's setting up the\n> aliases but never actually invoking them. I would have expected the\n> next line to actually run a command (\"git nested-internal-1\") and the\n> line after that to check that you got the expected output (whatever\n> \"git status\" would emit). Output from \"git status\" isn't necessarily\n> the easiest to test, though, so perhaps pick a different Git command\n> for testing (something for which the result can be very easily checked\n> -- maybe \"git rm\" or such).\n\nWhoops, I didn't know when that went missing. I added it into a new version\nof this patch.\n\nAlso, I decided to keep `git status`, because it seemed to be the only\ncommand which doesn't need any files to produce some checkable output.\nChecking the \"On branch\" message should be enough to confirm that the\ncommand works as intended.\n\n> \n>> +test_expect_success 'nested aliases - mixed execution' '\n>> + git config alias.nested-external-1 \"!git nested-external-2\" &&\n>> + git config alias.nested-external-2 status\n>> +'\n> \n> Same observation.\n> \n>> +test_expect_success 'looping aliases - internal execution' '\n>> + git config alias.loop-internal-1 loop-internal-2 &&\n>> + git config alias.loop-internal-2 loop-internal-3 &&\n>> + git config alias.loop-internal-3 loop-internal-2 &&\n>> + test_must_fail git loop-internal-1 2>output &&\n>> + grep -q \"fatal: alias loop detected: expansion of '\"'\"'loop-internal-1'\"'\"' does not terminate\" output &&\n> \n> Don't bother using -q with 'grep'. Output is hidden already by the\n> test framework in normal mode, and not hidden when running in verbose\n> mode. And, the output of 'grep' might be helpful when debugging the\n> test if something goes wrong.\n> \n> As noted above, you can use regex to match the expected error rather\n> than exactly duplicating the text of the message.\n> \n> Finally, use 'test_i18ngrep' instead of 'grep' in order to play nice\n> with localization.\n> \n>> + rm output\n> \n> Tests don't normally bother cleaning up their output files like this\n> since such output can be helpful when debugging the test if something\n> goes wrong. (You'd want to use test_when_finished to cleanup anyhow,\n> but you don't need it in this case.)\n\nI incorporated both of these suggestions.\n\n> \n>> +'\n> \n\nThis is the first multi-patch series that I submitted, so I'm unsure if I\nshould send the updated patch only or if I should send the complete series\nagain as v5. Any pointers to what the correct procedure for this case is would\nbe appreciated.\n\nThanks for looking at this.\n\nTim\n"},{"id":"358226","messageId":"CAPig+cT7+Rcv-xVxUCYy7LV6+bNEWJgN4qONLaYsikfZN40YMA@mail.gmail.com","threadId":"49280","inReplyTo":"bd63006e-18a7-1c41-252c-cf47a65ba7cb@gmx.de","subject":"Re: [RFC PATCH v4 3/3] t0014: Introduce alias testing suite","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-09-16T07:21:50Z","receivedAt":"2018-09-16T07:22:04Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Sep 14, 2018 at 7:12 PM Tim Schumacher wrote:\n> This is the first multi-patch series that I submitted, so I'm unsure if I\n> should send the updated patch only or if I should send the complete series\n> again as v5. Any pointers to what the correct procedure for this case is would\n> be appreciated.\n\nRe-send the entire series as v5. That makes it easier on reviewers\n(who don't need to go searching through the mailing list archive to\nget a full picture) and reduces Junio's workload since it's usually\neasier for him to re-queue a series wholesale than having to\nslice-and-dice some replacement patches into what was already queued.\n"},{"id":"358227","messageId":"aede75a5-d2ba-5a95-434d-aa70f7270fd7@gmx.de","threadId":"49280","inReplyTo":"CACsJy8BnHgaphwy3beCCquFjU=SZebR2GvDCkFgh1_snxDBTRQ@mail.gmail.com","subject":"Re: [RFC PATCH v4 1/3] Add support for nested aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-16T07:46:58Z","receivedAt":"2018-09-16T07:47:19Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"On 08.09.18 15:28, Duy Nguyen wrote:\n> On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:\n>> + /*\n>> + * It could be an alias -- this works around the insanity\n>> * of overriding \"git log\" with \"git show\" by having\n>> * alias.log = show\n>> */\n> \n> I think this comment block is about the next two lines you just\n> deleted. So delete it to instead of fixing style.\n\nI think that comment is talking about the code that is handing the alias,\nso it still would be valid.\nThe check might have peen placed in between to keep it logically grouped.\n\n> \n>> - if (done_alias)\n>> - break;\n>> if (!handle_alias(argcp, argv))\n>> break;\n>> done_alias = 1;\n>> }\n"},{"id":"358228","messageId":"20180916075002.3303-2-timschumi@gmx.de","threadId":"49280","inReplyTo":"20180916075002.3303-1-timschumi@gmx.de","subject":"[PATCH v5 2/3] Show the call history when an alias is looping","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-16T07:50:01Z","receivedAt":"2018-09-16T07:50:11Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"Just printing the command that the user entered is not particularly\nhelpful when trying to find the alias that causes the loop.\n\nPrint the history of substituted commands to help the user find the\noffending alias. Mark the entrypoint of the loop with \"<==\" and the\nlast command (which looped back to the entrypoint) with \"==>\".\n\nSigned-off-by: Tim Schumacher \n---\nNo changes since v4.\n\n git.c | 17 +++++++++++++++--\n 1 file changed, 15 insertions(+), 2 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex 15727c17f..a20eb4fa1 100644\n--- a/git.c\n+++ b/git.c\n@@ -675,6 +675,7 @@ static int run_argv(int *argcp, const char ***argv)\n {\n \tint done_alias = 0;\n \tstruct string_list cmd_list = STRING_LIST_INIT_NODUP;\n+\tstruct string_list_item *seen;\n \n \twhile (1) {\n \t\t/*\n@@ -692,9 +693,21 @@ static int run_argv(int *argcp, const char ***argv)\n \t\t/* .. then try the external ones */\n \t\texecv_dashed_external(*argv);\n \n-\t\tif (unsorted_string_list_has_string(&cmd_list, *argv[0])) {\n+\t\tseen = unsorted_string_list_lookup(&cmd_list, *argv[0]);\n+\t\tif (seen) {\n+\t\t\tint i;\n+\t\t\tstruct strbuf sb = STRBUF_INIT;\n+\t\t\tfor (i = 0; i < cmd_list.nr; i++) {\n+\t\t\t\tstruct string_list_item *item = &cmd_list.items[i];\n+\n+\t\t\t\tstrbuf_addf(&sb, \"\\n %s\", item->string);\n+\t\t\t\tif (item == seen)\n+\t\t\t\t\tstrbuf_addstr(&sb, \" <==\");\n+\t\t\t\telse if (i == cmd_list.nr - 1)\n+\t\t\t\t\tstrbuf_addstr(&sb, \" ==>\");\n+\t\t\t}\n \t\t\tdie(_(\"alias loop detected: expansion of '%s' does\"\n-\t\t\t \" not terminate\"), cmd_list.items[0].string);\n+\t\t\t \" not terminate:%s\"), cmd_list.items[0].string, sb.buf);\n \t\t}\n \n \t\tstring_list_append(&cmd_list, *argv[0]);\n-- \n2.19.0.rc2.1.g4c98b8d69.dirty\n\n"},{"id":"358229","messageId":"20180916075002.3303-3-timschumi@gmx.de","threadId":"49280","inReplyTo":"20180916075002.3303-1-timschumi@gmx.de","subject":"[PATCH v5 3/3] t0014: Introduce an alias testing suite","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-16T07:50:02Z","receivedAt":"2018-09-16T07:50:13Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"Introduce a testing suite that is dedicated to aliases.\nFor now, check only if nested aliases work and if looping\naliases are detected successfully.\n\nThe looping aliases check for mixed execution is there but\ndisabled, because it is blocking the test suite for a full\nminute. As soon as there is a solution for loops using\nexternal commands, it should be enabled.\n\nSigned-off-by: Tim Schumacher \n---\nChanges since v4:\n - Actually execute a command in the first two cases\n - Remove the \"setup code\"\n - Use i18ngrep to match the part of a message\n - Comment out the last test\n\n t/t0014-alias.sh | 40 ++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 40 insertions(+)\n create mode 100755 t/t0014-alias.sh\n\ndiff --git a/t/t0014-alias.sh b/t/t0014-alias.sh\nnew file mode 100755\nindex 000000000..a070e645d\n--- /dev/null\n+++ b/t/t0014-alias.sh\n@@ -0,0 +1,40 @@\n+#!/bin/sh\n+\n+test_description='git command aliasing'\n+\n+. ./test-lib.sh\n+\n+test_expect_success 'nested aliases - internal execution' '\n+\tgit config alias.nested-internal-1 nested-internal-2 &&\n+\tgit config alias.nested-internal-2 status &&\n+\tgit nested-internal-1 >output &&\n+\ttest_i18ngrep \"^On branch \" output\n+'\n+\n+test_expect_success 'nested aliases - mixed execution' '\n+\tgit config alias.nested-external-1 nested-external-2 &&\n+\tgit config alias.nested-external-2 \"!git nested-external-3\" &&\n+\tgit config alias.nested-external-3 status &&\n+\tgit nested-external-1 >output &&\n+\ttest_i18ngrep \"^On branch \" output\n+'\n+\n+test_expect_success 'looping aliases - internal execution' '\n+\tgit config alias.loop-internal-1 loop-internal-2 &&\n+\tgit config alias.loop-internal-2 loop-internal-3 &&\n+\tgit config alias.loop-internal-3 loop-internal-2 &&\n+\ttest_must_fail git loop-internal-1 2>output &&\n+\ttest_i18ngrep \"^fatal: alias loop detected: expansion of\" output\n+'\n+\n+# This test is disabled until external loops are fixed, because would block\n+# the test suite for a full minute.\n+#\n+#test_expect_failure 'looping aliases - mixed execution' '\n+#\tgit config alias.loop-mixed-1 loop-mixed-2 &&\n+#\tgit config alias.loop-mixed-2 \"!git loop-mixed-1\" &&\n+#\ttest_must_fail git loop-mixed-1 2>output &&\n+#\ttest_i18ngrep \"^fatal: alias loop detected: expansion of\" output\n+#'\n+\n+test_done\n-- \n2.19.0.rc2.1.g4c98b8d69.dirty\n\n"},{"id":"358230","messageId":"20180916075002.3303-1-timschumi@gmx.de","threadId":"49280","inReplyTo":"20180907224430.23859-1-timschumi@gmx.de","subject":"[PATCH v5 1/3] Add support for nested aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-16T07:50:00Z","receivedAt":"2018-09-16T07:50:13Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"Aliases can only contain non-alias git commands and their\narguments, not other user-defined aliases. Resolving further\n(nested) aliases is prevented by breaking the loop after the\nfirst alias was processed. Git then fails with a command-not-found\nerror.\n\nAllow resolving nested aliases by not breaking the loop in\nrun_argv() after the first alias was processed. Instead, continue\nthe loop until `handle_alias()` fails, which means that there are\nno further aliases that can be processed. Prevent looping aliases\nby storing substituted commands in `cmd_list` and checking if\na command has been substituted previously.\n\nWhile we're at it, fix a styling issue just below the added code.\n\nSigned-off-by: Tim Schumacher \n---\nChanges since v3:\n - Print the command that the user entered instead of the command\n which caused the loop (and a nicer, more explanatory error message)\n - Use unsorted_string_list_has_string() instead of the sorted version\n - Fix a code style issue just below the modified code\n - done_alias is a simple boolean again (instead of a counter)\n\nChanges since v4: None.\n\n git.c | 15 ++++++++++++---\n 1 file changed, 12 insertions(+), 3 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex c27c38738..15727c17f 100644\n--- a/git.c\n+++ b/git.c\n@@ -674,6 +674,7 @@ static void execv_dashed_external(const char **argv)\n static int run_argv(int *argcp, const char ***argv)\n {\n \tint done_alias = 0;\n+\tstruct string_list cmd_list = STRING_LIST_INIT_NODUP;\n \n \twhile (1) {\n \t\t/*\n@@ -691,17 +692,25 @@ static int run_argv(int *argcp, const char ***argv)\n \t\t/* .. then try the external ones */\n \t\texecv_dashed_external(*argv);\n \n-\t\t/* It could be an alias -- this works around the insanity\n+\t\tif (unsorted_string_list_has_string(&cmd_list, *argv[0])) {\n+\t\t\tdie(_(\"alias loop detected: expansion of '%s' does\"\n+\t\t\t \" not terminate\"), cmd_list.items[0].string);\n+\t\t}\n+\n+\t\tstring_list_append(&cmd_list, *argv[0]);\n+\n+\t\t/*\n+\t\t * It could be an alias -- this works around the insanity\n \t\t * of overriding \"git log\" with \"git show\" by having\n \t\t * alias.log = show\n \t\t */\n-\t\tif (done_alias)\n-\t\t\tbreak;\n \t\tif (!handle_alias(argcp, argv))\n \t\t\tbreak;\n \t\tdone_alias = 1;\n \t}\n \n+\tstring_list_clear(&cmd_list, 0);\n+\n \treturn done_alias;\n }\n \n-- \n2.19.0.rc2.1.g4c98b8d69.dirty\n\n"},{"id":"358279","messageId":"xmqqva7487a2.fsf@gitster-ct.c.googlers.com","threadId":"49280","inReplyTo":"aede75a5-d2ba-5a95-434d-aa70f7270fd7@gmx.de","subject":"Re: [RFC PATCH v4 1/3] Add support for nested aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-17T15:37:09Z","receivedAt":"2018-09-17T15:37:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tim Schumacher writes:\n\n> On 08.09.18 15:28, Duy Nguyen wrote:\n>> On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:\n>>> + /*\n>>> + * It could be an alias -- this works around the insanity\n>>> * of overriding \"git log\" with \"git show\" by having\n>>> * alias.log = show\n>>> */\n>>\n>> I think this comment block is about the next two lines you just\n>> deleted. So delete it to instead of fixing style.\n>\n> I think that comment is talking about the code that is handing the alias,\n> so it still would be valid.\n\n\"this\" in \"this works around\" refers to the fact that we first check\nthe builtins and on-GIT_EXEC_PATH commands before trying an alias,\nwhich is an effective way to forbid an alias from taking over\nexisting command names. So it is not about a particular code but is\nabout how the two sections of code are laid out.\n\nIt probably will make it clear if we reworded and made it a comment\nabout the whole while() loop may make sense, i.e.\n\n\t/*\n\t * Check if av[0] is a command before seeing if it is an\n\t * alias to avoid the insanity of overriding ...\n\t */\n\twhile (1) {\n\t\t...\n\nbut that can be done after the dust settles as a clean-up, I would\nthink.\n"},{"id":"358564","messageId":"9f7aa1f1-2493-42f3-19b7-cfa2efadbb14@gmx.de","threadId":"49280","inReplyTo":"xmqqva7487a2.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC PATCH v4 1/3] Add support for nested aliases","fromName":"Tim Schumacher","fromEmail":"timschumi@gmx.de","sentAt":"2018-09-21T12:45:56Z","receivedAt":"2018-09-21T12:46:23Z","isPatch":true,"sender":{"key":"timschumi@gmx.de","avatar":"https://avatars.githubusercontent.com/u/16820960?v=4"},"body":"On 17.09.18 17:37, Junio C Hamano wrote:\n> Tim Schumacher writes:\n> \n>> On 08.09.18 15:28, Duy Nguyen wrote:\n>>> On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:\n>>>> + /*\n>>>> + * It could be an alias -- this works around the insanity\n>>>> * of overriding \"git log\" with \"git show\" by having\n>>>> * alias.log = show\n>>>> */\n>>>\n>>> I think this comment block is about the next two lines you just\n>>> deleted. So delete it to instead of fixing style.\n>>\n>> I think that comment is talking about the code that is handing the alias,\n>> so it still would be valid.\n> \n> \"this\" in \"this works around\" refers to the fact that we first check\n> the builtins and on-GIT_EXEC_PATH commands before trying an alias,\n> which is an effective way to forbid an alias from taking over\n> existing command names. So it is not about a particular code but is\n> about how the two sections of code are laid out.\n> \n> It probably will make it clear if we reworded and made it a comment\n> about the whole while() loop may make sense, i.e.\n> \n> \t/*\n> \t * Check if av[0] is a command before seeing if it is an\n> \t * alias to avoid the insanity of overriding ...\n> \t */\n> \twhile (1) {\n> \t\t...\n> \n\nImho, the \"insanity\" part makes the intention of that comment unclear, even if\nit is located at the top of the while() loop. Giving an example is nice, but wouldn't\nit be better to say something like the following?\n\n\t/*\n\t * Check if av[0] is a command before seeing if it is an\n\t * alias to avoid taking over existing commands\n\t */\n\n> but that can be done after the dust settles as a clean-up, I would\n> think.\n> \n\nI'll keep the changed comment in my local repository for now and publish it together\nwith other changes in v6, but I assume there won't be much additional feedback.\n"},{"id":"358603","messageId":"xmqqa7oayh7z.fsf@gitster-ct.c.googlers.com","threadId":"49280","inReplyTo":"9f7aa1f1-2493-42f3-19b7-cfa2efadbb14@gmx.de","subject":"Re: [RFC PATCH v4 1/3] Add support for nested aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-21T15:59:12Z","receivedAt":"2018-09-21T15:59:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tim Schumacher writes:\n\n> it is located at the top of the while() loop. Giving an example is nice, but wouldn't\n> it be better to say something like the following?\n>\n> \t/*\n> \t * Check if av[0] is a command before seeing if it is an\n> \t * alias to avoid taking over existing commands\n> \t */\n\nIf we have more concrete and constructive things to explain why we\nchoose to forbid it, that may be worth saying, but I agree that it\ndoes not add much value to this comment to declare that an attempt\nto take over existing commands is \"insane\".\n\nThanks.\n"},{"id":"360882","messageId":"20181018225739.28857-1-avarab@gmail.com","threadId":"49280","inReplyTo":"87o9dar9qc.fsf@evledraar.gmail.com","subject":"[PATCH] alias: detect loops in mixed execution mode","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-18T22:57:39Z","receivedAt":"2018-10-18T22:57:53Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Add detection for aliasing loops in cases where one of the aliases\nre-invokes git as a shell command. This catches cases like:\n\n [alias]\n foo = !git bar\n bar = !git foo\n\nBefore this change running \"git {foo,bar}\" would create a\nforkbomb. Now using the aliasing loop detection and call history\nreporting added in 82f71d9a5a (\"alias: show the call history when an\nalias is looping\", 2018-09-16) and c6d75bc17a (\"alias: add support for\naliases of an alias\", 2018-09-16) we'll instead report:\n\n fatal: alias loop detected: expansion of 'foo' does not terminate:\n foo <==\n bar ==>\n\nSince the implementation carries the call history in an environment\nvariable, using the same sort of trick as used for -c (see\n2b64fc894d (\"pass \"git -c foo=bar\" params through environment\",\n2010-08-23) ). For example:\n\n [alias]\n one = two\n two = !git three\n three = four\n four = !git five\n five = two\n\nWill, on \"git one\" report:\n\n fatal: alias loop detected: expansion of 'one' does not terminate:\n one\n two <==\n three\n four\n five ==>\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n\nImplements what I suggested in\nhttps://public-inbox.org/git/87o9dar9qc.fsf@evledraar.gmail.com/\n\n cache.h | 1 +\n git.c | 36 ++++++++++++++++++++++++++++++++++--\n t/t0001-init.sh | 1 +\n t/t0014-alias.sh | 15 ++++++---------\n 4 files changed, 42 insertions(+), 11 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex d508f3d4f8..00cbd25f1c 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -478,6 +478,7 @@ static inline enum object_type object_type(unsigned int mode)\n #define TEMPLATE_DIR_ENVIRONMENT \"GIT_TEMPLATE_DIR\"\n #define CONFIG_ENVIRONMENT \"GIT_CONFIG\"\n #define CONFIG_DATA_ENVIRONMENT \"GIT_CONFIG_PARAMETERS\"\n+#define COMMAND_HISTORY_ENVIRONMENT \"GIT_COMMAND_HISTORY\"\n #define EXEC_PATH_ENVIRONMENT \"GIT_EXEC_PATH\"\n #define CEILING_DIRECTORIES_ENVIRONMENT \"GIT_CEILING_DIRECTORIES\"\n #define NO_REPLACE_OBJECTS_ENVIRONMENT \"GIT_NO_REPLACE_OBJECTS\"\ndiff --git a/git.c b/git.c\nindex 5920f8019b..cba242836c 100644\n--- a/git.c\n+++ b/git.c\n@@ -672,12 +672,43 @@ static void execv_dashed_external(const char **argv)\n \t\texit(128);\n }\n \n+static void init_cmd_history(struct strbuf *env, struct string_list *cmd_list)\n+{\n+\tconst char *old = getenv(COMMAND_HISTORY_ENVIRONMENT);\n+\tstruct strbuf **cmd_history, **ptr;\n+\n+\tif (!old || !*old)\n+\t\treturn;\n+\n+\tstrbuf_addstr(env, old);\n+\tstrbuf_rtrim(env);\n+\n+\tcmd_history = strbuf_split_buf(old, strlen(old), ' ', 0);\n+\tfor (ptr = cmd_history; *ptr; ptr++) {\n+\t\tstrbuf_rtrim(*ptr);\n+\t\tstring_list_append(cmd_list, (*ptr)->buf);\n+\t}\n+\tstrbuf_list_free(cmd_history);\n+}\n+\n+static void add_cmd_history(struct strbuf *env, struct string_list *cmd_list,\n+\t\t\t const char *cmd)\n+{\n+\tstring_list_append(cmd_list, cmd);\n+\tif (env->len)\n+\t\tstrbuf_addch(env, ' ');\n+\tstrbuf_addstr(env, cmd);\n+\tsetenv(COMMAND_HISTORY_ENVIRONMENT, env->buf, 1);\n+}\n+\n static int run_argv(int *argcp, const char ***argv)\n {\n \tint done_alias = 0;\n-\tstruct string_list cmd_list = STRING_LIST_INIT_NODUP;\n+\tstruct string_list cmd_list = STRING_LIST_INIT_DUP;\n \tstruct string_list_item *seen;\n+\tstruct strbuf env = STRBUF_INIT;\n \n+\tinit_cmd_history(&env, &cmd_list);\n \twhile (1) {\n \t\t/*\n \t\t * If we tried alias and futzed with our environment,\n@@ -711,7 +742,7 @@ static int run_argv(int *argcp, const char ***argv)\n \t\t\t \" not terminate:%s\"), cmd_list.items[0].string, sb.buf);\n \t\t}\n \n-\t\tstring_list_append(&cmd_list, *argv[0]);\n+\t\tadd_cmd_history(&env, &cmd_list, *argv[0]);\n \n \t\t/*\n \t\t * It could be an alias -- this works around the insanity\n@@ -724,6 +755,7 @@ static int run_argv(int *argcp, const char ***argv)\n \t}\n \n \tstring_list_clear(&cmd_list, 0);\n+\tstrbuf_release(&env);\n \n \treturn done_alias;\n }\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex 182da069f1..eb2ca8a172 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -93,6 +93,7 @@ test_expect_success 'No extra GIT_* on alias scripts' '\n \t\tsed -n \\\n \t\t\t-e \"/^GIT_PREFIX=/d\" \\\n \t\t\t-e \"/^GIT_TEXTDOMAINDIR=/d\" \\\n+\t\t\t-e \"/^GIT_COMMAND_HISTORY=/d\" \\\n \t\t\t-e \"/^GIT_/s/=.*//p\" |\n \t\tsort\n \tEOF\ndiff --git a/t/t0014-alias.sh b/t/t0014-alias.sh\nindex a070e645d7..9ed03a4a4f 100755\n--- a/t/t0014-alias.sh\n+++ b/t/t0014-alias.sh\n@@ -27,14 +27,11 @@ test_expect_success 'looping aliases - internal execution' '\n \ttest_i18ngrep \"^fatal: alias loop detected: expansion of\" output\n '\n \n-# This test is disabled until external loops are fixed, because would block\n-# the test suite for a full minute.\n-#\n-#test_expect_failure 'looping aliases - mixed execution' '\n-#\tgit config alias.loop-mixed-1 loop-mixed-2 &&\n-#\tgit config alias.loop-mixed-2 \"!git loop-mixed-1\" &&\n-#\ttest_must_fail git loop-mixed-1 2>output &&\n-#\ttest_i18ngrep \"^fatal: alias loop detected: expansion of\" output\n-#'\n+test_expect_success 'looping aliases - mixed execution' '\n+\tgit config alias.loop-mixed-1 loop-mixed-2 &&\n+\tgit config alias.loop-mixed-2 \"!git loop-mixed-1\" &&\n+\ttest_must_fail git loop-mixed-1 2>output &&\n+\ttest_i18ngrep \"^fatal: alias loop detected: expansion of\" output\n+'\n \n test_done\n-- \n2.19.1.568.g152ad8e336\n\n"},{"id":"360906","messageId":"87pnw6cpcp.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"20181018225739.28857-1-avarab@gmail.com","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-19T08:28:22Z","receivedAt":"2018-10-19T08:28:29Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 18 2018, Ævar Arnfjörð Bjarmason wrote:\n\n> +static void init_cmd_history(struct strbuf *env, struct string_list *cmd_list)\n> +{\n> +\tconst char *old = getenv(COMMAND_HISTORY_ENVIRONMENT);\n> +\tstruct strbuf **cmd_history, **ptr;\n> +\n> +\tif (!old || !*old)\n> +\t\treturn;\n> +\n> +\tstrbuf_addstr(env, old);\n> +\tstrbuf_rtrim(env);\n> +\n> +\tcmd_history = strbuf_split_buf(old, strlen(old), ' ', 0);\n> +\tfor (ptr = cmd_history; *ptr; ptr++) {\n> +\t\tstrbuf_rtrim(*ptr);\n> +\t\tstring_list_append(cmd_list, (*ptr)->buf);\n> +\t}\n> +\tstrbuf_list_free(cmd_history);\n> +}\n> +\n> +static void add_cmd_history(struct strbuf *env, struct string_list *cmd_list,\n> +\t\t\t const char *cmd)\n> +{\n> +\tstring_list_append(cmd_list, cmd);\n> +\tif (env->len)\n> +\t\tstrbuf_addch(env, ' ');\n> +\tstrbuf_addstr(env, cmd);\n> +\tsetenv(COMMAND_HISTORY_ENVIRONMENT, env->buf, 1);\n> +}\n> +\n> static int run_argv(int *argcp, const char ***argv)\n> {\n> \tint done_alias = 0;\n> -\tstruct string_list cmd_list = STRING_LIST_INIT_NODUP;\n> +\tstruct string_list cmd_list = STRING_LIST_INIT_DUP;\n> \tstruct string_list_item *seen;\n> +\tstruct strbuf env = STRBUF_INIT;\n>\n> +\tinit_cmd_history(&env, &cmd_list);\n> \twhile (1) {\n> \t\t/*\n> \t\t * If we tried alias and futzed with our environment,\n> @@ -711,7 +742,7 @@ static int run_argv(int *argcp, const char ***argv)\n> \t\t\t \" not terminate:%s\"), cmd_list.items[0].string, sb.buf);\n> \t\t}\n>\n> -\t\tstring_list_append(&cmd_list, *argv[0]);\n> +\t\tadd_cmd_history(&env, &cmd_list, *argv[0]);\n>\n> \t\t/*\n> \t\t * It could be an alias -- this works around the insanity\n\nJust to sanity check an assumption of mine: One thing I didn't do is use\nsq_quote_buf() and sq_dequote_to_argv() like we do for\nCONFIG_DATA_ENVIRONMENT. This is because in the case of config we need\nto deal with:\n\n $ git config alias.cfgdump\n !env\n $ git -c x.y=z -c \"foo.bar='baz'\" cfgdump|grep baz\n GIT_CONFIG_PARAMETERS='x.y=z' 'foo.bar='\\''baz'\\'''\n\nBut in this case I don't see how a command-name would ever contain\nwhitespace. So we skip quoting and just delimit by space.\n\nThere's also nothing stopping you from doing e.g.:\n\n $ GIT_COMMAND_HISTORY='foo bar' ~/g/git/git --exec-path=$PWD one\n fatal: alias loop detected: expansion of 'foo' does not terminate:\n foo\n bar\n one\n two <==\n three\n four\n five ==>\n\nOr even confuse the code by adding a whitespace at the beginning:\n\n $ GIT_COMMAND_HISTORY=' foo bar' ~/g/git/git --exec-path=$PWD one\n fatal: alias loop detected: expansion of '' does not terminate:\n\n foo\n bar\n one\n two <==\n three\n four\n five ==>\n\nI thought none of this was worth dealing with. Worst case someone's\nscrewing with this, but I don't see how it would happen accidentally,\nand even then we detect the infinite loop and just degrade to confusing\nerror messages because you decided to screw with git's GIT_* env vars.\n"},{"id":"360983","messageId":"20181019220755.GA31563@sigill.intra.peff.net","threadId":"49280","inReplyTo":"20181018225739.28857-1-avarab@gmail.com","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-19T22:07:55Z","receivedAt":"2018-10-19T22:07:58Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2018 at 10:57:39PM +0000, Ævar Arnfjörð Bjarmason wrote:\n\n> Add detection for aliasing loops in cases where one of the aliases\n> re-invokes git as a shell command. This catches cases like:\n> \n> [alias]\n> foo = !git bar\n> bar = !git foo\n> \n> Before this change running \"git {foo,bar}\" would create a\n> forkbomb. Now using the aliasing loop detection and call history\n> reporting added in 82f71d9a5a (\"alias: show the call history when an\n> alias is looping\", 2018-09-16) and c6d75bc17a (\"alias: add support for\n> aliases of an alias\", 2018-09-16) we'll instead report:\n> \n> fatal: alias loop detected: expansion of 'foo' does not terminate:\n> foo <==\n> bar ==>\n\nThe regular alias expansion can generally assume that there's no\nconditional recursion going on, because it's expanding everything\nitself. But when we involve multiple processes, things get trickier.\n\nFor instance, I could do this:\n\n [alias]\n countdown = \"!f() { echo \\\"$@\\\"; test \\\"$1\\\" -gt 0 && git countdown $(($1-1)); }; f\"\n\nwhich works now, but not with your patch.\n\nNow obviously that's a silly toy example, but are there real cases which\nmight trigger this? Some plausible ones I can think of:\n\n - an alias which handles some special cases, then chains to itself for\n the simpler one (or to another alias or script, which ends up\n chaining back to the original)\n\n - an alias that runs a git command, which then spawns a hook or other\n user-controlled script, which incidentally uses that same alias\n\nI'd guess this sort of thing is pretty rare. But I wonder if we're\ncrossing the line of trying to assume too much about what the user's\narbitrary code does.\n\nA simple depth counter can limit the fork bomb, and with a high enough\ndepth would be unlikely to trigger a false positive. It could also\nprotect non-aliases more reasonably, too (e.g., if you have a 1000-deep\ngit process hierarchy, there's a good chance you've found an infinite\nloop in git itself).\n\n> +static void init_cmd_history(struct strbuf *env, struct string_list *cmd_list)\n> +{\n> +\tconst char *old = getenv(COMMAND_HISTORY_ENVIRONMENT);\n> +\tstruct strbuf **cmd_history, **ptr;\n> +\n> +\tif (!old || !*old)\n> +\t\treturn;\n> +\n> +\tstrbuf_addstr(env, old);\n> +\tstrbuf_rtrim(env);\n> +\n> +\tcmd_history = strbuf_split_buf(old, strlen(old), ' ', 0);\n> +\tfor (ptr = cmd_history; *ptr; ptr++) {\n> +\t\tstrbuf_rtrim(*ptr);\n> +\t\tstring_list_append(cmd_list, (*ptr)->buf);\n> +\t}\n> +\tstrbuf_list_free(cmd_history);\n\nMaybe string_list_split() would be a little simpler?\n\n-Peff\n"},{"id":"360984","messageId":"20181019220946.GB31563@sigill.intra.peff.net","threadId":"49280","inReplyTo":"87pnw6cpcp.fsf@evledraar.gmail.com","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-19T22:09:47Z","receivedAt":"2018-10-19T22:09:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2018 at 10:28:22AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > -\t\tstring_list_append(&cmd_list, *argv[0]);\n> > +\t\tadd_cmd_history(&env, &cmd_list, *argv[0]);\n> >\n> > \t\t/*\n> > \t\t * It could be an alias -- this works around the insanity\n> \n> Just to sanity check an assumption of mine: One thing I didn't do is use\n> sq_quote_buf() and sq_dequote_to_argv() like we do for\n> CONFIG_DATA_ENVIRONMENT. This is because in the case of config we need\n> to deal with:\n> \n> $ git config alias.cfgdump\n> !env\n> $ git -c x.y=z -c \"foo.bar='baz'\" cfgdump|grep baz\n> GIT_CONFIG_PARAMETERS='x.y=z' 'foo.bar='\\''baz'\\'''\n> \n> But in this case I don't see how a command-name would ever contain\n> whitespace. So we skip quoting and just delimit by space.\n\nAlias names cannot currently contain whitespace, because it's not\nallowed in the key. However, we've discussed making the syntax\nalias..command, which would then make it possible.\n\nWhether anyone would use that is a different question, but hey,\napparently some people think \"My Documents\" is a good name for a\ndirectory. ;)\n\n-Peff\n"},{"id":"361001","messageId":"87h8hgdh5m.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"20181019220946.GB31563@sigill.intra.peff.net","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-20T10:52:21Z","receivedAt":"2018-10-20T10:52:29Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Oct 19 2018, Jeff King wrote:\n\n> On Fri, Oct 19, 2018 at 10:28:22AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> > -\t\tstring_list_append(&cmd_list, *argv[0]);\n>> > +\t\tadd_cmd_history(&env, &cmd_list, *argv[0]);\n>> >\n>> > \t\t/*\n>> > \t\t * It could be an alias -- this works around the insanity\n>>\n>> Just to sanity check an assumption of mine: One thing I didn't do is use\n>> sq_quote_buf() and sq_dequote_to_argv() like we do for\n>> CONFIG_DATA_ENVIRONMENT. This is because in the case of config we need\n>> to deal with:\n>>\n>> $ git config alias.cfgdump\n>> !env\n>> $ git -c x.y=z -c \"foo.bar='baz'\" cfgdump|grep baz\n>> GIT_CONFIG_PARAMETERS='x.y=z' 'foo.bar='\\''baz'\\'''\n>>\n>> But in this case I don't see how a command-name would ever contain\n>> whitespace. So we skip quoting and just delimit by space.\n>\n> Alias names cannot currently contain whitespace, because it's not\n> allowed in the key. However, we've discussed making the syntax\n> alias..command, which would then make it possible.\n>\n> Whether anyone would use that is a different question, but hey,\n> apparently some people think \"My Documents\" is a good name for a\n> directory. ;)\n\nI'll just leave this part as it is for now. If we ever have commands\nwith whitespace this'll be the least of our worries.\n"},{"id":"361002","messageId":"87ftx0dg4r.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"20181019220755.GA31563@sigill.intra.peff.net","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-20T11:14:28Z","receivedAt":"2018-10-20T11:14:34Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Oct 19 2018, Jeff King wrote:\n\n> On Thu, Oct 18, 2018 at 10:57:39PM +0000, Ævar Arnfjörð Bjarmason wrote:\n>\n>> Add detection for aliasing loops in cases where one of the aliases\n>> re-invokes git as a shell command. This catches cases like:\n>>\n>> [alias]\n>> foo = !git bar\n>> bar = !git foo\n>>\n>> Before this change running \"git {foo,bar}\" would create a\n>> forkbomb. Now using the aliasing loop detection and call history\n>> reporting added in 82f71d9a5a (\"alias: show the call history when an\n>> alias is looping\", 2018-09-16) and c6d75bc17a (\"alias: add support for\n>> aliases of an alias\", 2018-09-16) we'll instead report:\n>>\n>> fatal: alias loop detected: expansion of 'foo' does not terminate:\n>> foo <==\n>> bar ==>\n>\n> The regular alias expansion can generally assume that there's no\n> conditional recursion going on, because it's expanding everything\n> itself. But when we involve multiple processes, things get trickier.\n>\n> For instance, I could do this:\n>\n> [alias]\n> countdown = \"!f() { echo \\\"$@\\\"; test \\\"$1\\\" -gt 0 && git countdown $(($1-1)); }; f\"\n>\n> which works now, but not with your patch.\n>\n> Now obviously that's a silly toy example, but are there real cases which\n> might trigger this? Some plausible ones I can think of:\n>\n> - an alias which handles some special cases, then chains to itself for\n> the simpler one (or to another alias or script, which ends up\n> chaining back to the original)\n>\n> - an alias that runs a git command, which then spawns a hook or other\n> user-controlled script, which incidentally uses that same alias\n>\n> I'd guess this sort of thing is pretty rare. But I wonder if we're\n> crossing the line of trying to assume too much about what the user's\n> arbitrary code does.\n>\n> A simple depth counter can limit the fork bomb, and with a high enough\n> depth would be unlikely to trigger a false positive. It could also\n> protect non-aliases more reasonably, too (e.g., if you have a 1000-deep\n> git process hierarchy, there's a good chance you've found an infinite\n> loop in git itself).\n\nI don't think this edge case you're describing is very plausible, and I\ndoubt it exists in the wild.\n\nBut going by my personal incredulity and a git release breaking code in\nthe wild would suck, so agree that I need to re-roll this to anticipate\nthat.\n\nI don't have time to write it now, but what do you think about a version\nof this where we introduce a core.recursionLimit setting, and by default\nset it to \"1\" (for one recursion), so by default die just as we do now,\nbut with some advice() saying that we've bailed out early because this\nlooks crazy, but you can set it to e.g. \"1000\" if you think you know\nwhat you're doing, or \"0\" for no limit.\n\nThe reason I'd like to do that is because I think it's *way* more common\nto do this accidentally than intentionally, and by having a default\nlimit of 1000 we'd print a really long error message, or alternatively\nwould have to get into the mess of de-duplicating the callstack as we\nprint the error.\n\nIt also has the advantage that if people in the wild really use this\nthey'll chime in about this new annoying core.recursionLimit=1 setting,\nat the cost of me having annoyed them all by breaking their working\ncode.\n\n>> +static void init_cmd_history(struct strbuf *env, struct string_list *cmd_list)\n>> +{\n>> +\tconst char *old = getenv(COMMAND_HISTORY_ENVIRONMENT);\n>> +\tstruct strbuf **cmd_history, **ptr;\n>> +\n>> +\tif (!old || !*old)\n>> +\t\treturn;\n>> +\n>> +\tstrbuf_addstr(env, old);\n>> +\tstrbuf_rtrim(env);\n>> +\n>> +\tcmd_history = strbuf_split_buf(old, strlen(old), ' ', 0);\n>> +\tfor (ptr = cmd_history; *ptr; ptr++) {\n>> +\t\tstrbuf_rtrim(*ptr);\n>> +\t\tstring_list_append(cmd_list, (*ptr)->buf);\n>> +\t}\n>> +\tstrbuf_list_free(cmd_history);\n>\n> Maybe string_list_split() would be a little simpler?\n\nYeah looks like it. I cargo-culted this from elsewhere without looking\nat that API. I'll look into it.\n"},{"id":"361066","messageId":"20181020185852.GA6234@sigill.intra.peff.net","threadId":"49280","inReplyTo":"87ftx0dg4r.fsf@evledraar.gmail.com","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-20T18:58:53Z","receivedAt":"2018-10-20T18:58:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 20, 2018 at 01:14:28PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > I'd guess this sort of thing is pretty rare. But I wonder if we're\n> > crossing the line of trying to assume too much about what the user's\n> > arbitrary code does.\n> >\n> > A simple depth counter can limit the fork bomb, and with a high enough\n> > depth would be unlikely to trigger a false positive. It could also\n> > protect non-aliases more reasonably, too (e.g., if you have a 1000-deep\n> > git process hierarchy, there's a good chance you've found an infinite\n> > loop in git itself).\n> \n> I don't think this edge case you're describing is very plausible, and I\n> doubt it exists in the wild.\n> \n> But going by my personal incredulity and a git release breaking code in\n> the wild would suck, so agree that I need to re-roll this to anticipate\n> that.\n\nI agree it's probably quite rare, if it exists at all. But I also wonder\nhow important looping alias protection is. It's also rare, and the\noutcome is usually \"gee, I wonder why this is taking so long? ^C\".\n\nAt least that's my instinct. I don't remember having run into this at\nall myself (though certainly I have written my fair share of infinite\nloops in other systems, like bash aliases, and that is what happened).\n\n> I don't have time to write it now, but what do you think about a version\n> of this where we introduce a core.recursionLimit setting, and by default\n> set it to \"1\" (for one recursion), so by default die just as we do now,\n> but with some advice() saying that we've bailed out early because this\n> looks crazy, but you can set it to e.g. \"1000\" if you think you know\n> what you're doing, or \"0\" for no limit.\n> \n> The reason I'd like to do that is because I think it's *way* more common\n> to do this accidentally than intentionally, and by having a default\n> limit of 1000 we'd print a really long error message, or alternatively\n> would have to get into the mess of de-duplicating the callstack as we\n> print the error.\n\nWould we print a long error message? I'd assume that we'd just recurse\nfor longer and print one error message that says:\n\n fatal: woah, you're 1000-levels deep in Git commands!\n\nThat doesn't help the user find the recursion, but re-running with\nGIT_TRACE=1 would make it pretty clear, I'd think.\n\n> It also has the advantage that if people in the wild really use this\n> they'll chime in about this new annoying core.recursionLimit=1 setting,\n> at the cost of me having annoyed them all by breaking their working\n> code.\n\nRight, I'm not too happy about that annoyance. But it seems clear that I\nthink the loop protection is way less important than you do, so I'm\nwilling to sacrifice (or more accurately, risk the possibility of\nsacrificing) a lot less for it. :)\n\nI dunno. I doubt it is likely to help or hinder that many people either\nway.\n\n> >> +\tcmd_history = strbuf_split_buf(old, strlen(old), ' ', 0);\n> >> +\tfor (ptr = cmd_history; *ptr; ptr++) {\n> >> +\t\tstrbuf_rtrim(*ptr);\n> >> +\t\tstring_list_append(cmd_list, (*ptr)->buf);\n> >> +\t}\n> >> +\tstrbuf_list_free(cmd_history);\n> >\n> > Maybe string_list_split() would be a little simpler?\n> \n> Yeah looks like it. I cargo-culted this from elsewhere without looking\n> at that API. I'll look into it.\n\nI cheated before writing that and confirmed that it does seem to work. ;)\n\nHere's the patch in case it is useful. IMHO we should be trying to get\nrid of strbuf_split, because it's a pretty crappy interface.\n\ndiff --git a/git.c b/git.c\nindex cba242836c..9d1b66a1fa 100644\n--- a/git.c\n+++ b/git.c\n@@ -675,7 +675,6 @@ static void execv_dashed_external(const char **argv)\n static void init_cmd_history(struct strbuf *env, struct string_list *cmd_list)\n {\n \tconst char *old = getenv(COMMAND_HISTORY_ENVIRONMENT);\n-\tstruct strbuf **cmd_history, **ptr;\n \n \tif (!old || !*old)\n \t\treturn;\n@@ -683,12 +682,7 @@ static void init_cmd_history(struct strbuf *env, struct string_list *cmd_list)\n \tstrbuf_addstr(env, old);\n \tstrbuf_rtrim(env);\n \n-\tcmd_history = strbuf_split_buf(old, strlen(old), ' ', 0);\n-\tfor (ptr = cmd_history; *ptr; ptr++) {\n-\t\tstrbuf_rtrim(*ptr);\n-\t\tstring_list_append(cmd_list, (*ptr)->buf);\n-\t}\n-\tstrbuf_list_free(cmd_history);\n+\tstring_list_split(cmd_list, env->buf, ' ', -1);\n }\n \n static void add_cmd_history(struct strbuf *env, struct string_list *cmd_list,\n\n-Peff\n"},{"id":"361067","messageId":"87efckctqa.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"20181020185852.GA6234@sigill.intra.peff.net","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-20T19:18:21Z","receivedAt":"2018-10-20T19:18:28Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Oct 20 2018, Jeff King wrote:\n\n> On Sat, Oct 20, 2018 at 01:14:28PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> > I'd guess this sort of thing is pretty rare. But I wonder if we're\n>> > crossing the line of trying to assume too much about what the user's\n>> > arbitrary code does.\n>> >\n>> > A simple depth counter can limit the fork bomb, and with a high enough\n>> > depth would be unlikely to trigger a false positive. It could also\n>> > protect non-aliases more reasonably, too (e.g., if you have a 1000-deep\n>> > git process hierarchy, there's a good chance you've found an infinite\n>> > loop in git itself).\n>>\n>> I don't think this edge case you're describing is very plausible, and I\n>> doubt it exists in the wild.\n>>\n>> But going by my personal incredulity and a git release breaking code in\n>> the wild would suck, so agree that I need to re-roll this to anticipate\n>> that.\n>\n> I agree it's probably quite rare, if it exists at all. But I also wonder\n> how important looping alias protection is. It's also rare, and the\n> outcome is usually \"gee, I wonder why this is taking so long? ^C\".\n>\n> At least that's my instinct. I don't remember having run into this at\n> all myself (though certainly I have written my fair share of infinite\n> loops in other systems, like bash aliases, and that is what happened).\n>\n>> I don't have time to write it now, but what do you think about a version\n>> of this where we introduce a core.recursionLimit setting, and by default\n>> set it to \"1\" (for one recursion), so by default die just as we do now,\n>> but with some advice() saying that we've bailed out early because this\n>> looks crazy, but you can set it to e.g. \"1000\" if you think you know\n>> what you're doing, or \"0\" for no limit.\n>>\n>> The reason I'd like to do that is because I think it's *way* more common\n>> to do this accidentally than intentionally, and by having a default\n>> limit of 1000 we'd print a really long error message, or alternatively\n>> would have to get into the mess of de-duplicating the callstack as we\n>> print the error.\n>\n> Would we print a long error message? I'd assume that we'd just recurse\n> for longer and print one error message that says:\n>\n> fatal: woah, you're 1000-levels deep in Git commands!\n>\n> That doesn't help the user find the recursion, but re-running with\n> GIT_TRACE=1 would make it pretty clear, I'd think.\n\nYeah the reason I'd like the core.recursionLimit=1 setting by default is\nso that we can also print the same pretty and easy to grok error message\nwe do now for non-! aliases by default without spewing out ~3-4k lines\nof mostly duplicate output (with a default limit of 1000).\n\nWe didn't support chained aliases at all before, so I think the odds\nthat people will run into this now will increase as they add \"!\" to\nexisting aliases, and I'd like to have git's UI friendly enough to tell\nusers what went wrong by default, and not have to resort to the likes of\nGIT_TRACE=1 which really should be left to powerusers.\n\n>> It also has the advantage that if people in the wild really use this\n>> they'll chime in about this new annoying core.recursionLimit=1 setting,\n>> at the cost of me having annoyed them all by breaking their working\n>> code.\n>\n> Right, I'm not too happy about that annoyance. But it seems clear that I\n> think the loop protection is way less important than you do, so I'm\n> willing to sacrifice (or more accurately, risk the possibility of\n> sacrificing) a lot less for it. :)\n>\n> I dunno. I doubt it is likely to help or hinder that many people either\n> way.\n>\n>> >> +\tcmd_history = strbuf_split_buf(old, strlen(old), ' ', 0);\n>> >> +\tfor (ptr = cmd_history; *ptr; ptr++) {\n>> >> +\t\tstrbuf_rtrim(*ptr);\n>> >> +\t\tstring_list_append(cmd_list, (*ptr)->buf);\n>> >> +\t}\n>> >> +\tstrbuf_list_free(cmd_history);\n>> >\n>> > Maybe string_list_split() would be a little simpler?\n>>\n>> Yeah looks like it. I cargo-culted this from elsewhere without looking\n>> at that API. I'll look into it.\n>\n> I cheated before writing that and confirmed that it does seem to work. ;)\n>\n> Here's the patch in case it is useful. IMHO we should be trying to get\n> rid of strbuf_split, because it's a pretty crappy interface.\n>\n> diff --git a/git.c b/git.c\n> index cba242836c..9d1b66a1fa 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -675,7 +675,6 @@ static void execv_dashed_external(const char **argv)\n> static void init_cmd_history(struct strbuf *env, struct string_list *cmd_list)\n> {\n> \tconst char *old = getenv(COMMAND_HISTORY_ENVIRONMENT);\n> -\tstruct strbuf **cmd_history, **ptr;\n>\n> \tif (!old || !*old)\n> \t\treturn;\n> @@ -683,12 +682,7 @@ static void init_cmd_history(struct strbuf *env, struct string_list *cmd_list)\n> \tstrbuf_addstr(env, old);\n> \tstrbuf_rtrim(env);\n>\n> -\tcmd_history = strbuf_split_buf(old, strlen(old), ' ', 0);\n> -\tfor (ptr = cmd_history; *ptr; ptr++) {\n> -\t\tstrbuf_rtrim(*ptr);\n> -\t\tstring_list_append(cmd_list, (*ptr)->buf);\n> -\t}\n> -\tstrbuf_list_free(cmd_history);\n> +\tstring_list_split(cmd_list, env->buf, ' ', -1);\n> }\n>\n> static void add_cmd_history(struct strbuf *env, struct string_list *cmd_list,\n\nThanks! Will squash it.\n"},{"id":"361105","messageId":"xmqq5zxuzsei.fsf@gitster-ct.c.googlers.com","threadId":"49280","inReplyTo":"20181020185852.GA6234@sigill.intra.peff.net","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-22T01:23:01Z","receivedAt":"2018-10-22T01:23:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I agree it's probably quite rare, if it exists at all. But I also wonder\n> how important looping alias protection is. It's also rare, and the\n> outcome is usually \"gee, I wonder why this is taking so long? ^C\".\n>\n> At least that's my instinct. I don't remember having run into this at\n> all myself (though certainly I have written my fair share of infinite\n> loops in other systems, like bash aliases, and that is what happened).\n\nYup, that instict is shared with me, and I tend to prefer something\nbased on a simple counter for that reason.\n\n> Would we print a long error message? I'd assume that we'd just recurse\n> for longer and print one error message that says:\n>\n> fatal: woah, you're 1000-levels deep in Git commands!\n>\n> That doesn't help the user find the recursion, but re-running with\n> GIT_TRACE=1 would make it pretty clear, I'd think.\n\nThanks.\n"},{"id":"361203","messageId":"20181022211545.GA15713@sigill.intra.peff.net","threadId":"49280","inReplyTo":"87efckctqa.fsf@evledraar.gmail.com","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-22T21:15:45Z","receivedAt":"2018-10-22T21:15:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 20, 2018 at 09:18:21PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> We didn't support chained aliases at all before, so I think the odds\n> that people will run into this now will increase as they add \"!\" to\n> existing aliases, and I'd like to have git's UI friendly enough to tell\n> users what went wrong by default, and not have to resort to the likes of\n> GIT_TRACE=1 which really should be left to powerusers.\n\nIt's true that non-! aliases couldn't recurse before, but couldn't \"!\"\nones always do so?\n\n-Peff\n"},{"id":"361204","messageId":"877ei9d634.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"20181022211545.GA15713@sigill.intra.peff.net","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-22T21:28:15Z","receivedAt":"2018-10-22T21:28:21Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Oct 22 2018, Jeff King wrote:\n\n> On Sat, Oct 20, 2018 at 09:18:21PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> We didn't support chained aliases at all before, so I think the odds\n>> that people will run into this now will increase as they add \"!\" to\n>> existing aliases, and I'd like to have git's UI friendly enough to tell\n>> users what went wrong by default, and not have to resort to the likes of\n>> GIT_TRACE=1 which really should be left to powerusers.\n>\n> It's true that non-! aliases couldn't recurse before, but couldn't \"!\"\n> ones always do so?\n\nYes. I meant that maybe now it's a feature that works for that people\nwill start using it, and then convert some of that to !-aliases they\nwouldn't otherwise have written. Just idle speculation...\n"},{"id":"361612","messageId":"20181026083905.GA1705@sigill.intra.peff.net","threadId":"49280","inReplyTo":"20181020185852.GA6234@sigill.intra.peff.net","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-26T08:39:05Z","receivedAt":"2018-10-26T08:39:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 20, 2018 at 02:58:53PM -0400, Jeff King wrote:\n\n> On Sat, Oct 20, 2018 at 01:14:28PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> \n> > > I'd guess this sort of thing is pretty rare. But I wonder if we're\n> > > crossing the line of trying to assume too much about what the user's\n> > > arbitrary code does.\n> > >\n> > > A simple depth counter can limit the fork bomb, and with a high enough\n> > > depth would be unlikely to trigger a false positive. It could also\n> > > protect non-aliases more reasonably, too (e.g., if you have a 1000-deep\n> > > git process hierarchy, there's a good chance you've found an infinite\n> > > loop in git itself).\n> > \n> > I don't think this edge case you're describing is very plausible, and I\n> > doubt it exists in the wild.\n> > \n> > But going by my personal incredulity and a git release breaking code in\n> > the wild would suck, so agree that I need to re-roll this to anticipate\n> > that.\n> \n> I agree it's probably quite rare, if it exists at all. But I also wonder\n> how important looping alias protection is. It's also rare, and the\n> outcome is usually \"gee, I wonder why this is taking so long? ^C\".\n\nHmph. So I was speaking before purely hypothetically, but now that your\npatch is in 'next', it is part of my daily build. And indeed, I hit a\nfalse positive within 5 minutes of building it. ;)\n\nI have an alias like this:\n\n $ git help dotgit\n 'dotgit' is aliased to '!git rev-parse 2>/dev/null || cd ~/compile/git; git'\n\nThe idea being that I can run \"git dotgit foo\" to run \"git foo\" in the\ncurrent directory, or if it is not a git repository, in my checkout of\ngit.git.\n\nI use it in two ways:\n\n - some of my aliases know about it themselves. So I have an alias \"ll\"\n that does:\n\n $ git help ll\n 'll' is aliased to '!git dotgit --no-pager log --no-walk=unsorted --format='%h (%s, %ad)' --date=short'\n\n with the idea being to produce a nice annotation for a commit id.\n Using \"git dotgit\" there lets me just run it from any directory,\n since 99% of the time I am working on git.git anyway.\n\n - I have a vim command defined:\n\n command! -nargs=* Git :call MaybeInlineCommand(\"git dotgit \")\n\n so I can do \":Git foo\" inside vim and it uses either the current\n repo (e.g., if I'm writing a commit message) or git.git (e.g., if\n I'm writing an email and didn't start in the repo).\n\nSo of course the alias expansion is something like (in older versions of\nGit):\n\n 1. \"git dotgit ll\" runs the dotgit alias, which sees that we need to go\n to the git.git checkout\n\n 2. that runs \"git ll\"\n\n 3. that runs \"git dotgit log\"; this second dotgit invocation sees we're\n already in a repository and is a noop\n\n 4. git-log runs\n\nWith your patch, step 3 complains:\n\n $ git dotgit ll\n fatal: alias loop detected: expansion of 'dotgit' does not terminate:\n dotgit <==\n ll ==>\n\nSo I would really prefer a depth counter that can be set sufficiently\nhigh to make this case work. ;)\n\n\nAs an aside, I got to experience this error message as an unsuspecting\nuser would. Unfortunately the output was not super helpful for figuring\nout the cause. I scratched my head for a while before remembering that\n\"ll\" uses \"dotgit\" explicitly (which was quite apparent when running\nGIT_TRACE=1, or \"git help ll\"). I think showing the alias definitions in\nthe loop output would have made it much more obvious (if perhaps a bit\nuglier). E.g., something like:\n\n fatal: alias loop...\n ==> dotgit is aliased to '!git rev-parse ...'\n <== ll is aliased to '!git dotgit ...'\n\n-Peff\n"},{"id":"361619","messageId":"87sh0slvxm.fsf@evledraar.gmail.com","threadId":"49280","inReplyTo":"20181026083905.GA1705@sigill.intra.peff.net","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-26T12:44:05Z","receivedAt":"2018-10-26T12:44:12Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Oct 26 2018, Jeff King wrote:\n\n> On Sat, Oct 20, 2018 at 02:58:53PM -0400, Jeff King wrote:\n>\n>> On Sat, Oct 20, 2018 at 01:14:28PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> > > I'd guess this sort of thing is pretty rare. But I wonder if we're\n>> > > crossing the line of trying to assume too much about what the user's\n>> > > arbitrary code does.\n>> > >\n>> > > A simple depth counter can limit the fork bomb, and with a high enough\n>> > > depth would be unlikely to trigger a false positive. It could also\n>> > > protect non-aliases more reasonably, too (e.g., if you have a 1000-deep\n>> > > git process hierarchy, there's a good chance you've found an infinite\n>> > > loop in git itself).\n>> >\n>> > I don't think this edge case you're describing is very plausible, and I\n>> > doubt it exists in the wild.\n>> >\n>> > But going by my personal incredulity and a git release breaking code in\n>> > the wild would suck, so agree that I need to re-roll this to anticipate\n>> > that.\n>>\n>> I agree it's probably quite rare, if it exists at all. But I also wonder\n>> how important looping alias protection is. It's also rare, and the\n>> outcome is usually \"gee, I wonder why this is taking so long? ^C\".\n>\n> Hmph. So I was speaking before purely hypothetically, but now that your\n> patch is in 'next', it is part of my daily build. And indeed, I hit a\n> false positive within 5 minutes of building it. ;)\n>\n> I have an alias like this:\n>\n> $ git help dotgit\n> 'dotgit' is aliased to '!git rev-parse 2>/dev/null || cd ~/compile/git; git'\n>\n> The idea being that I can run \"git dotgit foo\" to run \"git foo\" in the\n> current directory, or if it is not a git repository, in my checkout of\n> git.git.\n>\n> I use it in two ways:\n>\n> - some of my aliases know about it themselves. So I have an alias \"ll\"\n> that does:\n>\n> $ git help ll\n> 'll' is aliased to '!git dotgit --no-pager log --no-walk=unsorted --format='%h (%s, %ad)' --date=short'\n>\n> with the idea being to produce a nice annotation for a commit id.\n> Using \"git dotgit\" there lets me just run it from any directory,\n> since 99% of the time I am working on git.git anyway.\n>\n> - I have a vim command defined:\n>\n> command! -nargs=* Git :call MaybeInlineCommand(\"git dotgit \")\n>\n> so I can do \":Git foo\" inside vim and it uses either the current\n> repo (e.g., if I'm writing a commit message) or git.git (e.g., if\n> I'm writing an email and didn't start in the repo).\n>\n> So of course the alias expansion is something like (in older versions of\n> Git):\n>\n> 1. \"git dotgit ll\" runs the dotgit alias, which sees that we need to go\n> to the git.git checkout\n>\n> 2. that runs \"git ll\"\n>\n> 3. that runs \"git dotgit log\"; this second dotgit invocation sees we're\n> already in a repository and is a noop\n>\n> 4. git-log runs\n>\n> With your patch, step 3 complains:\n>\n> $ git dotgit ll\n> fatal: alias loop detected: expansion of 'dotgit' does not terminate:\n> dotgit <==\n> ll ==>\n>\n> So I would really prefer a depth counter that can be set sufficiently\n> high to make this case work. ;)\n>\n>\n> As an aside, I got to experience this error message as an unsuspecting\n> user would. Unfortunately the output was not super helpful for figuring\n> out the cause. I scratched my head for a while before remembering that\n> \"ll\" uses \"dotgit\" explicitly (which was quite apparent when running\n> GIT_TRACE=1, or \"git help ll\"). I think showing the alias definitions in\n> the loop output would have made it much more obvious (if perhaps a bit\n> uglier). E.g., something like:\n>\n> fatal: alias loop...\n> ==> dotgit is aliased to '!git rev-parse ...'\n> <== ll is aliased to '!git dotgit ...'\n>\n> -Peff\n\nYikes.\n\nJunio: After your previous \"What's cooking\" in\n I sent\n<87ftx0dg4r.fsf@evledraar.gmail.com>, but should have just replied to\n\"What's cooking\".\n\nI.e. I think this topic should just be ejected, I'll try to submit a\nre-roll, but don't know if I have time in the next few days.\n\nCan you please queue a \"git revert\" of it (or rewind next, but not sure\nif you want to do that...).\n"},{"id":"361867","messageId":"xmqqefc976x1.fsf@gitster-ct.c.googlers.com","threadId":"49280","inReplyTo":"20181026083905.GA1705@sigill.intra.peff.net","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-29T03:44:58Z","receivedAt":"2018-10-29T03:45:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Hmph. So I was speaking before purely hypothetically, but now that your\n> patch is in 'next', it is part of my daily build. And indeed, I hit a\n> false positive within 5 minutes of building it. ;)\n\nSounds like somebody is having not-so-fun-a-time having \"I told you\nso\" moment. The 'dotgit' thing already feels bit convoluted but I\nwould say that it is still within the realm of reasonable workflow\nelements.\n\n> ...\n> With your patch, step 3 complains:\n>\n> $ git dotgit ll\n> fatal: alias loop detected: expansion of 'dotgit' does not terminate:\n> dotgit <==\n> ll ==>\n>\n> So I would really prefer a depth counter that can be set sufficiently\n> high to make this case work. ;)\n\nSounds like a concrete enough case to demonstrate why one-level deep\nloop detector is not sufficient X-<.\n"},{"id":"361898","messageId":"20181029141706.GB17668@sigill.intra.peff.net","threadId":"49280","inReplyTo":"xmqqefc976x1.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] alias: detect loops in mixed execution mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-29T14:17:06Z","receivedAt":"2018-10-29T14:17:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 29, 2018 at 12:44:58PM +0900, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Hmph. So I was speaking before purely hypothetically, but now that your\n> > patch is in 'next', it is part of my daily build. And indeed, I hit a\n> > false positive within 5 minutes of building it. ;)\n> \n> Sounds like somebody is having not-so-fun-a-time having \"I told you\n> so\" moment. The 'dotgit' thing already feels bit convoluted but I\n> would say that it is still within the realm of reasonable workflow\n> elements.\n\nTo be clear, the \"dotgit\" thing _is_ weird and convoluted. And I imagine\nthat I push Git more than 99% of our users would. But I also won't be\nsurprised if somebody else has something similarly disgusting in the\nwild. :)\n\nTBH, I'm still not really sold on the idea of doing loop detection at\nall in this case. But I can live with it if others feel strongly. What\nmakes the current patch so bad is that there's no escape hatch (i.e.,\neven a depth counter with a default of \"1\" would have given me something\nI could bump).\n\n-Peff\n"}]}