diff options
author | Jacob Keller <jacob.keller@gmail.com> | 2017-04-13 10:12:23 -0700 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-04-17 19:04:16 -0700 |
commit | 2e5d6503bdc92260eae9c58b9fd1add7014bb853 (patch) | |
tree | 4ef9a62575c503270339318afa7a0e7bef73a860 /t/t4013 | |
parent | Twelfth batch for 2.13 (diff) | |
download | tgif-2e5d6503bdc92260eae9c58b9fd1add7014bb853.tar.xz |
ls-files: fix recurse-submodules with nested submodules
Since commit e77aa336f116 ("ls-files: optionally recurse into
submodules", 2016-10-07) ls-files has known how to recurse into
submodules when displaying files.
Unfortunately this fails for certain cases, including when nesting more
than one submodule, called from within a submodule that itself has
submodules, or when the GIT_DIR environemnt variable is set.
Prior to commit b58a68c1c187 ("setup: allow for prefix to be passed to
git commands", 2017-03-17) this resulted in an error indicating that
--prefix and --super-prefix were incompatible.
After this commit, instead, the process loops forever with a GIT_DIR set
to the parent and continuously reads the parent submodule files and
recursing forever.
Fix this by preparing the environment properly for submodules when
setting up the child process. This is similar to how other commands such
as grep behave.
This was not caught by the original tests because the scenario is
avoided if the submodules are created separately and not stored as the
standard method of putting the submodule git directory under
.git/modules/<name>. We can update the test to show the failure by the
addition of "git submodule absorbgitdirs" to the test case. However,
note that this new test would run forever without the necessary fix in
this patch.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4013')
0 files changed, 0 insertions, 0 deletions