{"thread":{"id":"54219","subject":"[PATCH] ls-files: respect 'submodule.recurse' config","startedAt":"2020-09-10T03:09:14Z","lastAt":"2020-09-13T10:52:09Z","messageCount":10,"participants":["Philippe Blain via GitGitGadget","Junio C Hamano","Philippe Blain","Đoàn Trần Công Danh"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"405306","messageId":"pull.732.git.1599707259907.gitgitgadget@gmail.com","threadId":"54219","inReplyTo":null,"subject":"[PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Philippe Blain via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-09-10T03:07:39Z","receivedAt":"2020-09-10T03:09:14Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"From: Philippe Blain \n\n`git ls-files` learned to recurse into submodules when given\n'--recurse-submodules' back in e77aa336f1 (ls-files: optionally recurse\ninto submodules, 2016-10-07) but it does not respect the\n'submodule.recurse' config option which was later introduced in\n046b48239e (Introduce 'submodule.recurse' option for worktree\nmanipulators, 2017-05-31).\n\nAdd a 'git_ls_files_config' function to read this configuration\nvariable, and adjust the documentation and tests accordingly.\n\nSigned-off-by: Philippe Blain \n---\n ls-files: respect 'submodule.recurse' config\n \n This follows the approach of 121e43fa53 (pull: honor submodule.recurse\n config option, 2017-09-06)\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-732%2Fphil-blain%2Fls-files-submodule.recurse-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-732/phil-blain/ls-files-submodule.recurse-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/732\n\n Documentation/config/submodule.txt | 4 +--\n builtin/ls-files.c | 16 ++++++++++-\n t/t3007-ls-files-recurse-submodules.sh | 37 ++++++++++++++++++++++++++\n 3 files changed, 54 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config/submodule.txt b/Documentation/config/submodule.txt\nindex d7a63c8c12..9ba3adbf48 100644\n--- a/Documentation/config/submodule.txt\n+++ b/Documentation/config/submodule.txt\n@@ -60,8 +60,8 @@ submodule.active::\n submodule.recurse::\n \tSpecifies if commands recurse into submodules by default. This\n \tapplies to all commands that have a `--recurse-submodules` option\n-\t(`checkout`, `fetch`, `grep`, `pull`, `push`, `read-tree`, `reset`,\n-\t`restore` and `switch`) except `clone` and `ls-files`.\n+\t(`checkout`, `fetch`, `grep`, `ls-files`, `pull`, `push`, `read-tree`,\n+\t`reset`, `restore` and `switch`) except `clone` .\n \tDefaults to false.\n \tWhen set to true, it can be deactivated via the\n \t`--no-recurse-submodules` option. Note that some Git commands\ndiff --git a/builtin/ls-files.c b/builtin/ls-files.c\nindex c8eae899b8..43c7c9bd62 100644\n--- a/builtin/ls-files.c\n+++ b/builtin/ls-files.c\n@@ -512,6 +512,20 @@ static int option_parse_exclude_standard(const struct option *opt,\n \treturn 0;\n }\n \n+/**\n+ * Read config variables.\n+ */\n+static int git_ls_files_config(const char *var, const char *value, void *cb)\n+{\n+\tif (!strcmp(var, \"submodule.recurse\")) {\n+\t\trecurse_submodules = git_config_bool(var, value) ?\n+\t\t\tRECURSE_SUBMODULES_ON : RECURSE_SUBMODULES_OFF;\n+\t\treturn 0;\n+\t}\n+\n+\treturn git_default_config(var, value, cb);\n+}\n+\n int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)\n {\n \tint require_work_tree = 0, show_tag = 0, i;\n@@ -588,7 +602,7 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)\n \tprefix = cmd_prefix;\n \tif (prefix)\n \t\tprefix_len = strlen(prefix);\n-\tgit_config(git_default_config, NULL);\n+\tgit_config(git_ls_files_config, NULL);\n \n \tif (repo_read_index(the_repository) < 0)\n \t\tdie(\"index file corrupt\");\ndiff --git a/t/t3007-ls-files-recurse-submodules.sh b/t/t3007-ls-files-recurse-submodules.sh\nindex 4a08000713..30c2c1e0bd 100755\n--- a/t/t3007-ls-files-recurse-submodules.sh\n+++ b/t/t3007-ls-files-recurse-submodules.sh\n@@ -34,6 +34,43 @@ test_expect_success 'ls-files correctly outputs files in submodule' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'ls-files respects submodule.recurse' '\n+\tcat >expect <<-\\EOF &&\n+\t.gitmodules\n+\ta\n+\tb/b\n+\tsubmodule/c\n+\tEOF\n+\n+\tgit -c submodule.recurse ls-files >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success '--[no-]recurse-submodule and submodule.recurse' '\n+\tcat >expect-recurse <<-\\EOF &&\n+\t.gitmodules\n+\ta\n+\tb/b\n+\tsubmodule/c\n+\tEOF\n+\n+\tcat >expect-no-recurse <<-\\EOF &&\n+\t.gitmodules\n+\ta\n+\tb/b\n+\tsubmodule\n+\tEOF\n+\n+\tgit -c submodule.recurse ls-files --no-recurse-submodules >actual &&\n+\ttest_cmp expect-no-recurse actual &&\n+\tgit -c submodule.recurse=false ls-files --recurse-submodules >actual &&\n+\ttest_cmp expect-recurse actual &&\n+\tgit -c submodule.recurse=false ls-files --no-recurse-submodules >actual &&\n+\ttest_cmp expect-no-recurse actual &&\n+\tgit -c submodule.recurse ls-files --recurse-submodules >actual &&\n+\ttest_cmp expect-recurse actual\n+'\n+\n test_expect_success 'ls-files correctly outputs files in submodule with -z' '\n \tlf_to_nul >expect <<-\\EOF &&\n \t.gitmodules\n\nbase-commit: e19713638985533ce461db072b49112da5bd2042\n-- \ngitgitgadget\n"},{"id":"405309","messageId":"xmqqv9gms1fp.fsf@gitster.c.googlers.com","threadId":"54219","inReplyTo":"pull.732.git.1599707259907.gitgitgadget@gmail.com","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-10T04:25:30Z","receivedAt":"2020-09-10T04:25:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philippe Blain via GitGitGadget\" writes:\n\n> From: Philippe Blain \n>\n> `git ls-files` learned to recurse into submodules when given\n> '--recurse-submodules' back in e77aa336f1 (ls-files: optionally recurse\n> into submodules, 2016-10-07) but it does not respect the\n> 'submodule.recurse' config option which was later introduced in\n> 046b48239e (Introduce 'submodule.recurse' option for worktree\n> manipulators, 2017-05-31).\n>\n> Add a 'git_ls_files_config' function to read this configuration\n> variable, and adjust the documentation and tests accordingly.\n\nI am afraid that this will break existing scripts big time, and I\nwould not be surprised if 046b48239e refrained to do the equivalent\nof this patch very much on purpose to avoid such a regression.\n\nAnybody who writes a script using ls-files _without_ passing the\n--recurse-submodules option expects that the ls-files command will\nstop at submodule boundary without recursing, that the script can\nnotice and pick up mode 160000 entries in the output from ls-files,\nand that the script can decide if it wants to descend into\nsubmodules it discovered that way.\n\nIt is easy to imagine that such a script will break badly when run\nby a user who has the configuration variable set, I would think.\n\nIt also is easy to imagine a script derived from \"git-submodule.sh\"\nback from the time before we started rewriting pieces of it in C.\nThe main \"discover and list the immediate submodules we have\" code\nwas ls-files piped to a loop that picks up entries with mode 160000,\nand it was used to drive all the \"git submodule\" subcommands. As\nthe scripted version was not the world's greatest code, it is quite\nplausible that somebody forked and improved it, without feeding the\nchanges back to us. Such a script is also a candidate to be broken\nwith this patch.\n\nSo, no. I am not enthused to see this change.\n"},{"id":"405311","messageId":"xmqqmu1ys09f.fsf@gitster.c.googlers.com","threadId":"54219","inReplyTo":"xmqqv9gms1fp.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-10T04:50:52Z","receivedAt":"2020-09-10T04:51:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> So, no. I am not enthused to see this change.\n\nA more relevant question to ask you is what the motivation behind\nthis change is. \n\nIf it is an apparent \"inconsistency\" that the plumbing command in\nquestion takes an explicit command line option but ignores user\nconfiguration, then we can stop there---I think we would want to\nkeep it that way.\n\nBut if it is because \"I use this command interactively quite often,\nand I find it inconvenient because I need to type the long command\nline option\", we may want to step back and understand why you need\nto run the low level plumbing command in your interactive use case.\nPerhaps most, but not quite all, of your need, whatever it is, is\nalready satisfied by higher level commands (like \"status\"?) and what\nwe need is to enrich these end-user facing higher level commands to\nfill the \"gap\" to satisfy the need in your use case.\n\n"},{"id":"405406","messageId":"45EB4E9E-1819-41D6-839E-A3812456478C@gmail.com","threadId":"54219","inReplyTo":"xmqqv9gms1fp.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-09-11T13:05:42Z","receivedAt":"2020-09-11T14:18:45Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Junio,\n\n> Le 10 sept. 2020 à 00:25, Junio C Hamano a écrit :\n> \n> \"Philippe Blain via GitGitGadget\" writes:\n> \n>> From: Philippe Blain \n>> \n>> `git ls-files` learned to recurse into submodules when given\n>> '--recurse-submodules' back in e77aa336f1 (ls-files: optionally recurse\n>> into submodules, 2016-10-07) but it does not respect the\n>> 'submodule.recurse' config option which was later introduced in\n>> 046b48239e (Introduce 'submodule.recurse' option for worktree\n>> manipulators, 2017-05-31).\n>> \n>> Add a 'git_ls_files_config' function to read this configuration\n>> variable, and adjust the documentation and tests accordingly.\n> \n> I am afraid that this will break existing scripts big time, and I\n> would not be surprised if 046b48239e refrained to do the equivalent\n> of this patch very much on purpose to avoid such a regression.\n\nAs I read it, 046b48239e was just the introduction of the config and\nit's implementation for read-tree/checkout/reset, and the other commands\nwith '--recurse-submodules' would come later (as was done in the following \ncommits in branch 'sb/submodule-blanket-recursive').\n\nAlso, in gitsubmodules(7) [1], 'ls-files' is used as if it respects 'submodule.recurse',\nso I think that was Stefan's original plan. (It's been that way since the introduction\nof that man page in d48034551a).\n\n> Anybody who writes a script using ls-files _without_ passing the\n> --recurse-submodules option expects that the ls-files command will\n> stop at submodule boundary without recursing, that the script can\n> notice and pick up mode 160000 entries in the output from ls-files,\n> and that the script can decide if it wants to descend into\n> submodules it discovered that way.\n> \n> It is easy to imagine that such a script will break badly when run\n> by a user who has the configuration variable set, I would think.\n\nI understand, but I would argue that such a user could easily adapt their\nscript to add '--no-recurse-submodules' to their ls-files invocation if that \nis the case, no ?\n\n> So, no. I am not enthused to see this change.\n\nOK, if I'm not able to change your mind, what would you think of a separate\nconfig variable then, say `ls-files.recurseSubmodules` ? This would be more granular,\nso less chance of breaking existing scripts, but still provide for a way to configure \nGit to always recurse in submodules, including for 'ls-files'...\n\nThanks,\nPhilippe.\n\n\n[1] https://git-scm.com/docs/gitsubmodules#_workflow_for_an_artificially_split_repo\n\n"},{"id":"405407","messageId":"3384182A-89F6-45A4-AD65-57B0E2B95FFA@gmail.com","threadId":"54219","inReplyTo":"xmqqmu1ys09f.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-09-11T13:11:18Z","receivedAt":"2020-09-11T14:36:05Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"\n> Le 10 sept. 2020 à 00:50, Junio C Hamano a écrit :\n> \n> Junio C Hamano writes:\n> \n>> So, no. I am not enthused to see this change.\n> \n> A more relevant question to ask you is what the motivation behind\n> this change is. \n> \n> If it is an apparent \"inconsistency\" that the plumbing command in\n> question takes an explicit command line option but ignores user\n> configuration, then we can stop there---I think we would want to\n> keep it that way.\n\nYes, in part this (and as I said in my previous email, to bring the code in\nline with 'gitsubmodules(7)').\n\n> But if it is because \"I use this command interactively quite often,\n> and I find it inconvenient because I need to type the long command\n> line option\", we may want to step back and understand why you need\n> to run the low level plumbing command in your interactive use case.\n> Perhaps most, but not quite all, of your need, whatever it is, is\n> already satisfied by higher level commands (like \"status\"?) and what\n> we need is to enrich these end-user facing higher level commands to\n> fill the \"gap\" to satisfy the need in your use case.\n\nYes, I use ls-files interactively quite often. For example, I know a source file\nis named 'such_and_such' but I don't remember where in the directory hierarchy\nof the project it is located, so `git ls-files **/such_and_such` is the quickest way to \nfind it (and I have to then add '--recurse-submodules' when I get no results, remember\nthat the file in in a submodule, and rerun the command). So I use it mostly\nas a Git-aware find(1) replacement.\n\n"},{"id":"405411","messageId":"7D473EAB-7395-4904-A4F4-9EE13662998B@gmail.com","threadId":"54219","inReplyTo":"xmqqv9gms1fp.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-09-11T13:48:54Z","receivedAt":"2020-09-11T15:58:27Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Junio,\n\n> Le 10 sept. 2020 à 00:25, Junio C Hamano a écrit :\n> \n> \"Philippe Blain via GitGitGadget\" writes:\n> \n>> From: Philippe Blain \n>> \n>> `git ls-files` learned to recurse into submodules when given\n>> '--recurse-submodules' back in e77aa336f1 (ls-files: optionally recurse\n>> into submodules, 2016-10-07) but it does not respect the\n>> 'submodule.recurse' config option which was later introduced in\n>> 046b48239e (Introduce 'submodule.recurse' option for worktree\n>> manipulators, 2017-05-31).\n>> \n>> Add a 'git_ls_files_config' function to read this configuration\n>> variable, and adjust the documentation and tests accordingly.\n> \n> I am afraid that this will break existing scripts big time, and I\n> would not be surprised if 046b48239e refrained to do the equivalent\n> of this patch very much on purpose to avoid such a regression.\n\nAs I read it, 046b48239e was just the introduction of the config and\nit's implementation for read-tree/checkout/reset, and the other commands\nwith '--recurse-submodules' would come later (as was done in the following \ncommits in branch 'sb/submodule-blanket-recursive').\n\nAlso, in gitsubmodules(7) [1], 'ls-files' is used as if it respects 'submodule.recurse',\nso I think that was Stefan's original plan. (It's been that way since the introduction\nof that man page in d48034551a).\n\n> Anybody who writes a script using ls-files _without_ passing the\n> --recurse-submodules option expects that the ls-files command will\n> stop at submodule boundary without recursing, that the script can\n> notice and pick up mode 160000 entries in the output from ls-files,\n> and that the script can decide if it wants to descend into\n> submodules it discovered that way.\n> \n> It is easy to imagine that such a script will break badly when run\n> by a user who has the configuration variable set, I would think.\n\nI understand, but I would argue that such a user could easily adapt their\nscript to add '--no-recurse-submodules' to their ls-files invocation if that \nis the case, no ?\n\n> So, no. I am not enthused to see this change.\n\nOK, if I'm not able to change your mind, what would you think of a separate\nconfig variable then, say `ls-files.recurseSubmodules` ? This would be more granular,\nso less chance of breaking existing scripts, but still provide for a way to configure \nGit to always recurse in submodules, including for 'ls-files'...\n\nThanks,\nPhilippe.\n\n\n[1] https://git-scm.com/docs/gitsubmodules#_workflow_for_an_artificially_split_repo\n\n"},{"id":"405414","messageId":"F8142F2B-A707-4896-A03D-2EB71FD95A56@gmail.com","threadId":"54219","inReplyTo":"xmqqmu1ys09f.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-09-11T14:30:41Z","receivedAt":"2020-09-11T16:44:25Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"\n> Le 10 sept. 2020 à 00:50, Junio C Hamano a écrit :\n> \n> Junio C Hamano writes:\n> \n>> So, no. I am not enthused to see this change.\n> \n> A more relevant question to ask you is what the motivation behind\n> this change is. \n> \n> If it is an apparent \"inconsistency\" that the plumbing command in\n> question takes an explicit command line option but ignores user\n> configuration, then we can stop there---I think we would want to\n> keep it that way.\n\nYes, in part this (and as I said in my previous email, to bring the code in\nline with 'gitsubmodules(7)').\n\n> But if it is because \"I use this command interactively quite often,\n> and I find it inconvenient because I need to type the long command\n> line option\", we may want to step back and understand why you need\n> to run the low level plumbing command in your interactive use case.\n> Perhaps most, but not quite all, of your need, whatever it is, is\n> already satisfied by higher level commands (like \"status\"?) and what\n> we need is to enrich these end-user facing higher level commands to\n> fill the \"gap\" to satisfy the need in your use case.\n\nYes, I use ls-files interactively quite often. For example, I know a source file\nis named 'such_and_such' but I don't remember where in the directory hierarchy\nof the project it is located, so `git ls-files **/such_and_such` is the quickest way to \nfind it (and I have to then add '--recurse-submodules' when I get no results, remember\nthat the file in in a submodule, and rerun the command). So I use it mostly\nas a Git-aware find(1) replacement.\n\n"},{"id":"405443","messageId":"xmqqk0x0nmto.fsf@gitster.c.googlers.com","threadId":"54219","inReplyTo":"45EB4E9E-1819-41D6-839E-A3812456478C@gmail.com","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-11T19:19:15Z","receivedAt":"2020-09-11T19:19:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philippe Blain writes:\n\n> I understand, but I would argue that such a user could easily adapt their\n> script to add '--no-recurse-submodules' to their ls-files invocation if that \n> is the case, no ?\n\nIt would have been quite a different story if we were designing\n\"ls-files\" and adding support for \"--[no-]recurse-submodules\" and\n\"submodule.recurse\" to the command at the same time. To those who\nwrite scripts with \"ls-files\" and complain that the command behaves\ndifferently depending on the configuration, you can legitimately say\n\"you can use --no-recurse-submodules and you are fine\" in that case.\n\nBut not after all these years. The same statement becomes \"even if\nI broke the command, users could work around the breakage I caused\".\nThat is nothing more than a lame excuse that does not explay why you\nthink you have the right to break their script in the first place.\n\nSo, no, I am not enthused to see this change. Regardless of which\nconfiguration variable affects the feature. For those who wrote and\nuse scripts that run ls-files, it is a regression to invite unneeded\ncomplaints from their end-users who suddenly see the breakage in the\nscripts.\n\n\n\n"},{"id":"405488","messageId":"20200913104703.GA2034@danh.dev","threadId":"54219","inReplyTo":"45EB4E9E-1819-41D6-839E-A3812456478C@gmail.com","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-09-13T10:47:03Z","receivedAt":"2020-09-13T10:47:11Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-09-11 09:05:42-0400, Philippe Blain wrote:\n> I understand, but I would argue that such a user could easily adapt their\n> script to add '--no-recurse-submodules' to their ls-files invocation if that \n> is the case, no ?\n\nThere're people still live in the past, for example those poor souls\nstill live in Ubuntu 16.04 LTS, they don't have the luxury of using\nGit with ls-files that understand --recurse-submodules and\n--no-recurse-submodules.\n\n> > So, no. I am not enthused to see this change.\n> \n> OK, if I'm not able to change your mind, what would you think of a separate\n> config variable then, say `ls-files.recurseSubmodules` ? This would be more granular,\n> so less chance of breaking existing scripts, but still provide for a way to configure \n> Git to always recurse in submodules, including for 'ls-files'...\n\nIf you're really buy into configuration and using ls-files\ninteractively, I think it's better to make a Git-alias instead.\n\n\talias.ls = ls-files --recurse-submodules\n\n-- \nDanh\n"},{"id":"405489","messageId":"20200913105151.GA18403@danh.dev","threadId":"54219","inReplyTo":"20200913104703.GA2034@danh.dev","subject":"Re: [PATCH] ls-files: respect 'submodule.recurse' config","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-09-13T10:51:51Z","receivedAt":"2020-09-13T10:52:09Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-09-13 17:47:03+0700, Đoàn Trần Công Danh wrote:\n> On 2020-09-11 09:05:42-0400, Philippe Blain wrote:\n> > I understand, but I would argue that such a user could easily adapt their\n> > script to add '--no-recurse-submodules' to their ls-files invocation if that \n> > is the case, no ?\n> \n> There're people still live in the past, for example those poor souls\n> still live in Ubuntu 16.04 LTS, they don't have the luxury of using\n> Git with ls-files that understand --recurse-submodules and\n> --no-recurse-submodules.\n\nFor this statement, I meant:\n\n: those poor souls that needs to write script for both old and new machine.\n\nSorry for missing that information, and this noise.\n\n> > > So, no. I am not enthused to see this change.\n> > \n> > OK, if I'm not able to change your mind, what would you think of a separate\n> > config variable then, say `ls-files.recurseSubmodules` ? This would be more granular,\n> > so less chance of breaking existing scripts, but still provide for a way to configure \n> > Git to always recurse in submodules, including for 'ls-files'...\n> \n> If you're really buy into configuration and using ls-files\n> interactively, I think it's better to make a Git-alias instead.\n> \n> \talias.ls = ls-files --recurse-submodules\n\n-- \nDanh\n"}]}