These two patches introduce a test case which triggers a regression
introduced by a62387b3fc9f5aeeb04a2db278121d33a9caafa7 and a revert of
the commit introducing the issue.
The test case reproduces following scenario:
Repository setup:
superproject/middle_repo/inner_repo
Person A and B have both a clone of it, while Person B is not working
with the inner_repo and thus does not have it initialized in his working
copy.
Now person A does a change to the inner_repo and propagates it through
the middle_repo and the superproject.
Once person A pushed the changes, a "git fetch" on superproject level of
person B will return with error saying:
Could not access submodule 'inner_repo'
Errors during submodule fetch:
middle_repo
The revert was my quick approach to fix it. However as I'm not fully
aware of what the idea was behind handling the submodules inside
.git/modules instead of the worktree, I don't know whether this is the
best solution. Maybe rethinking the whole get_next_submodule()
algorithm or simply fixing the is_empty_dir() to use the worktree path
will be a better solution.
best regards,
--peter;
Peter Kaestle (2):
submodules: test for fetch of non-init subsub-repo
Revert "submodule.c: fetch in submodules git directory instead of in
worktree"
submodule.c | 14 ++++----------
t/t5526-fetch-submodules.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 10 deletions(-)
--
2.6.2
