On Thu, Aug 2, 2018 at 6:47 AM Antonio Ospite <a...@ao2.it> wrote: > > In t/t7506-status-submodule.sh at some point a new scenario is set up to > test different things, in particular new submodules are added which are > meant to completely replace the previous ones. > > However before calling the "git submodule add" commands for the new > layout, the .gitmodules file is removed only from the working tree still > leaving the previous content in current branch. > > This can break if, in the future, "git submodule add" starts > differentiating between the following two cases: > > - .gitmodules is not in the working tree but it is in the current > branch (it may not be safe to add new submodules in this case); > > - .gitmodules is neither in the working tree nor anywhere in the > current branch (it is safe to add new submodules). > > Since the test means to get rid of .gitmodules anyways, let's completely > remove it from the current branch, to actually start afresh in the new > scenario. > > This is more future-proof and does not break current tests.
Makes sense. Thanks, Stefan > > Signed-off-by: Antonio Ospite <a...@ao2.it> > --- > t/t7506-status-submodule.sh | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/t/t7506-status-submodule.sh b/t/t7506-status-submodule.sh > index b4b74dbe29..af91ba92ff 100755 > --- a/t/t7506-status-submodule.sh > +++ b/t/t7506-status-submodule.sh > @@ -325,7 +325,8 @@ test_expect_success 'setup superproject with untracked > file in nested submodule' > ( > cd super && > git clean -dfx && > - rm .gitmodules && > + git rm .gitmodules && > + git commit -m "remove .gitmodules" && > git submodule add -f ./sub1 && > git submodule add -f ./sub2 && > git submodule add -f ./sub1 sub3 && > -- > 2.18.0 >
