{"thread":{"id":"46612","subject":"[PATCH] add test for bug in git-mv with nested submodules","startedAt":"2017-08-17T10:34:25Z","lastAt":"2017-09-20T13:46:49Z","messageCount":8,"participants":["Heiko Voigt","Stefan Beller","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"326596","messageId":"20170817103413.GA52233@book.hvoigt.net","threadId":"46612","inReplyTo":null,"subject":"[PATCH] add test for bug in git-mv with nested submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-08-17T10:34:13Z","receivedAt":"2017-08-17T10:34:25Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"When using git-mv with a submodule it will detect that and update the\npaths for its configurations (.gitmodules, worktree and gitfile). This\ndoes not work for nested submodules where a user renames the root\nsubmodule.\n\nWe discovered this fact when working on on-demand fetch for renamed\nsubmodules. Lets add a test to document.\n\nSigned-off-by: Heiko Voigt <hvoigt@hvoigt.net>\n---\n t/t7001-mv.sh | 9 +++++++++\n 1 file changed, 9 insertions(+)\n\ndiff --git a/t/t7001-mv.sh b/t/t7001-mv.sh\nindex e365d1f..39f8aed 100755\n--- a/t/t7001-mv.sh\n+++ b/t/t7001-mv.sh\n@@ -491,4 +491,13 @@ test_expect_success 'moving a submodule in nested directories' '\n \ttest_cmp actual expect\n '\n \n+test_expect_failure 'moving nested submodules' '\n+\tgit commit -am \"cleanup commit\" &&\n+\tgit submodule add ./. sub_nested &&\n+\tgit commit -m \"add sub_nested\" &&\n+\tgit submodule update --init --recursive &&\n+\tgit mv sub_nested sub_nested_moved &&\n+\tgit status\n+'\n+\n test_done\n-- \n2.0.0.274.g6b2cd91\n\n"},{"id":"326625","messageId":"CAGZ79kZhUO95oSEzARqXi3+dm5Ow5Jwm-O1adowh0nkbqHdhMw@mail.gmail.com","threadId":"46612","inReplyTo":"20170817103413.GA52233@book.hvoigt.net","subject":"Re: [PATCH] add test for bug in git-mv with nested submodules","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-17T19:05:56Z","receivedAt":"2017-08-17T19:06:02Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Aug 17, 2017 at 3:34 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:\n> When using git-mv with a submodule it will detect that and update the\n> paths for its configurations (.gitmodules, worktree and gitfile). This\n> does not work for nested submodules where a user renames the root\n> submodule.\n>\n> We discovered this fact when working on on-demand fetch for renamed\n> submodules. Lets add a test to document.\n>\n> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>\n> ---\n>  t/t7001-mv.sh | 9 +++++++++\n>  1 file changed, 9 insertions(+)\n>\n> diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh\n> index e365d1f..39f8aed 100755\n> --- a/t/t7001-mv.sh\n> +++ b/t/t7001-mv.sh\n> @@ -491,4 +491,13 @@ test_expect_success 'moving a submodule in nested directories' '\n>         test_cmp actual expect\n>  '\n>\n> +test_expect_failure 'moving nested submodules' '\n> +       git commit -am \"cleanup commit\" &&\n> +       git submodule add ./. sub_nested &&\n\nIf possible, I would avoid adding the repo itself\nas a submodule as it is unrealistic in the wild.\n\nWhile it may be ok for the test here, later down the road\nother tests making use of it it may become an issue with\nthe URL of the submodule.\n\n> +       git commit -m \"add sub_nested\" &&\n> +       git submodule update --init --recursive &&\n> +       git mv sub_nested sub_nested_moved &&\n> +       git status\n> +'\n> +\n>  test_done\n> --\n> 2.0.0.274.g6b2cd91\n>\n"},{"id":"326703","messageId":"20170818160603.GA69414@book.hvoigt.net","threadId":"46612","inReplyTo":"CAGZ79kZhUO95oSEzARqXi3+dm5Ow5Jwm-O1adowh0nkbqHdhMw@mail.gmail.com","subject":"Re: [PATCH] add test for bug in git-mv with nested submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-08-18T16:06:03Z","receivedAt":"2017-08-18T17:25:16Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Thu, Aug 17, 2017 at 12:05:56PM -0700, Stefan Beller wrote:\n> On Thu, Aug 17, 2017 at 3:34 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:\n> > When using git-mv with a submodule it will detect that and update the\n> > paths for its configurations (.gitmodules, worktree and gitfile). This\n> > does not work for nested submodules where a user renames the root\n> > submodule.\n> >\n> > We discovered this fact when working on on-demand fetch for renamed\n> > submodules. Lets add a test to document.\n> >\n> > Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>\n> > ---\n> >  t/t7001-mv.sh | 9 +++++++++\n> >  1 file changed, 9 insertions(+)\n> >\n> > diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh\n> > index e365d1f..39f8aed 100755\n> > --- a/t/t7001-mv.sh\n> > +++ b/t/t7001-mv.sh\n> > @@ -491,4 +491,13 @@ test_expect_success 'moving a submodule in nested directories' '\n> >         test_cmp actual expect\n> >  '\n> >\n> > +test_expect_failure 'moving nested submodules' '\n> > +       git commit -am \"cleanup commit\" &&\n> > +       git submodule add ./. sub_nested &&\n> \n> If possible, I would avoid adding the repo itself\n> as a submodule as it is unrealistic in the wild.\n> \n> While it may be ok for the test here, later down the road\n> other tests making use of it it may become an issue with\n> the URL of the submodule.\n\nI just copied the shortcut that they were adding themselfes as submodule\nin 'setup submodule'. The whole setup of submodules in this test is like\nthis. This way we already had a nested submodule structure which I could\njust add.\n\nI agree that this is unrealistic so I can change that in the test I am\nadding. But from what I have seen, this shortcut is taken in quite some\nplaces when dealing with submodules.\n\nCheers Heiko\n"},{"id":"326711","messageId":"CAGZ79kYNLo_3PfLTOE5wusTs6wgFXZLVH+qNZ-ovxGguhinHLg@mail.gmail.com","threadId":"46612","inReplyTo":"20170818160603.GA69414@book.hvoigt.net","subject":"Re: [PATCH] add test for bug in git-mv with nested submodules","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-18T19:04:03Z","receivedAt":"2017-08-18T19:04:09Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> I just copied the shortcut that they were adding themselfes as submodule\n> in 'setup submodule'. The whole setup of submodules in this test is like\n> this. This way we already had a nested submodule structure which I could\n> just add.\n>\n> I agree that this is unrealistic so I can change that in the test I am\n> adding. But from what I have seen, this shortcut is taken in quite some\n> places when dealing with submodules.\n\nPlease do not make it worse.\nOnce upon a time (late '16 IIRC) I had a series floating on the\nlist removing all occurrences, but there were issues with the\nseries and it did not land.\n"},{"id":"328120","messageId":"20170915115021.GB76244@book.hvoigt.net","threadId":"46612","inReplyTo":"CAGZ79kYNLo_3PfLTOE5wusTs6wgFXZLVH+qNZ-ovxGguhinHLg@mail.gmail.com","subject":"[PATCH v2] add test for bug in git-mv for recursive submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-09-15T11:50:21Z","receivedAt":"2017-09-15T11:50:34Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"When using git-mv with a submodule it will detect that and update the\npaths for its configurations (.gitmodules, worktree and gitfile). This\ndoes not work for recursive submodules where a user renames the root\nsubmodule.\n\nWe discovered this fact when working on on-demand fetch for renamed\nsubmodules. Lets add a test to document.\n\nSigned-off-by: Heiko Voigt <hvoigt@hvoigt.net>\n---\nOn Fri, Aug 18, 2017 at 12:04:03PM -0700, Stefan Beller wrote:\n> > I just copied the shortcut that they were adding themselfes as submodule\n> > in 'setup submodule'. The whole setup of submodules in this test is like\n> > this. This way we already had a nested submodule structure which I could\n> > just add.\n> >\n> > I agree that this is unrealistic so I can change that in the test I am\n> > adding. But from what I have seen, this shortcut is taken in quite some\n> > places when dealing with submodules.\n> \n> Please do not make it worse.\n> Once upon a time (late '16 IIRC) I had a series floating on the\n> list removing all occurrences, but there were issues with the\n> series and it did not land.\n\nTook a little while but here is a more clean patch creating individual\nsubmodules for the nesting.\n\nCheers Heiko\n\n t/t7001-mv.sh | 25 +++++++++++++++++++++++++\n 1 file changed, 25 insertions(+)\n\ndiff --git a/t/t7001-mv.sh b/t/t7001-mv.sh\nindex e365d1ff77..cbc5fb37fe 100755\n--- a/t/t7001-mv.sh\n+++ b/t/t7001-mv.sh\n@@ -491,4 +491,29 @@ test_expect_success 'moving a submodule in nested directories' '\n \ttest_cmp actual expect\n '\n \n+test_expect_failure 'moving nested submodules' '\n+\tgit commit -am \"cleanup commit\" &&\n+\tmkdir sub_nested_nested &&\n+\t(cd sub_nested_nested &&\n+\t\ttouch nested_level2 &&\n+\t\tgit init &&\n+\t\tgit add . &&\n+\t\tgit commit -m \"nested level 2\"\n+\t) &&\n+\tmkdir sub_nested &&\n+\t(cd sub_nested &&\n+\t\ttouch nested_level1 &&\n+\t\tgit init &&\n+\t\tgit add . &&\n+\t\tgit commit -m \"nested level 1\"\n+\t\tgit submodule add ../sub_nested_nested &&\n+\t\tgit commit -m \"add nested level 2\"\n+\t) &&\n+\tgit submodule add ./sub_nested nested_move &&\n+\tgit commit -m \"add nested_move\" &&\n+\tgit submodule update --init --recursive &&\n+\tgit mv nested_move sub_nested_moved &&\n+\tgit status\n+'\n+\n test_done\n-- \n2.14.1.145.gb3622a4\n\n"},{"id":"328237","messageId":"xmqqlgleup78.fsf@gitster.mtv.corp.google.com","threadId":"46612","inReplyTo":"20170915115021.GB76244@book.hvoigt.net","subject":"Re: [PATCH v2] add test for bug in git-mv for recursive submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-17T00:46:35Z","receivedAt":"2017-09-17T00:48:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt <hvoigt@hvoigt.net> writes:\n\n> When using git-mv with a submodule it will detect that and update the\n> paths for its configurations (.gitmodules, worktree and gitfile). This\n> does not work for recursive submodules where a user renames the root\n> submodule.\n>\n> We discovered this fact when working on on-demand fetch for renamed\n> submodules. Lets add a test to document.\n>\n> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>\n> ---\n> On Fri, Aug 18, 2017 at 12:04:03PM -0700, Stefan Beller wrote:\n>> > I just copied the shortcut that they were adding themselfes as submodule\n>> > in 'setup submodule'. The whole setup of submodules in this test is like\n>> > this. This way we already had a nested submodule structure which I could\n>> > just add.\n>> >\n>> > I agree that this is unrealistic so I can change that in the test I am\n>> > adding. But from what I have seen, this shortcut is taken in quite some\n>> > places when dealing with submodules.\n>> \n>> Please do not make it worse.\n>> Once upon a time (late '16 IIRC) I had a series floating on the\n>> list removing all occurrences, but there were issues with the\n>> series and it did not land.\n>\n> Took a little while but here is a more clean patch creating individual\n> submodules for the nesting.\n>\n> Cheers Heiko\n\nThanks.  Stefan, does this look good to you now?\n\nIt is not quite clear which step is expected to fail with the\ncurrent code by reading the test or the proposed log message.  Does\n\"mv\" refuse to work and we do not get to run \"status\", or does\n\"status\" report a failure, or do we fail well before that?\n\nThe log message that only says \"This does not work when ...\" is not\nhelpful in figuring it out, either.  Something like \"This does not\nwork and fails to update the paths for its configurations\" or\nwhatever that describes \"what actually happens\" (in contrast to\n\"what ought to happen\", which you described clearly) should be\nthere.  \n\nDescription on how you happened to have discovered the issue feels a\nlot less relevant compared to that, and it is totally useless if it\nis unclear what the issue is in the first place.\n\n>  t/t7001-mv.sh | 25 +++++++++++++++++++++++++\n>  1 file changed, 25 insertions(+)\n>\n> diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh\n> index e365d1ff77..cbc5fb37fe 100755\n> --- a/t/t7001-mv.sh\n> +++ b/t/t7001-mv.sh\n> @@ -491,4 +491,29 @@ test_expect_success 'moving a submodule in nested directories' '\n>  \ttest_cmp actual expect\n>  '\n>  \n> +test_expect_failure 'moving nested submodules' '\n> +\tgit commit -am \"cleanup commit\" &&\n> +\tmkdir sub_nested_nested &&\n> +\t(cd sub_nested_nested &&\n> +\t\ttouch nested_level2 &&\n> +\t\tgit init &&\n> +\t\tgit add . &&\n> +\t\tgit commit -m \"nested level 2\"\n> +\t) &&\n> +\tmkdir sub_nested &&\n> +\t(cd sub_nested &&\n> +\t\ttouch nested_level1 &&\n> +\t\tgit init &&\n> +\t\tgit add . &&\n> +\t\tgit commit -m \"nested level 1\"\n> +\t\tgit submodule add ../sub_nested_nested &&\n> +\t\tgit commit -m \"add nested level 2\"\n> +\t) &&\n> +\tgit submodule add ./sub_nested nested_move &&\n> +\tgit commit -m \"add nested_move\" &&\n> +\tgit submodule update --init --recursive &&\n> +\tgit mv nested_move sub_nested_moved &&\n> +\tgit status\n> +'\n> +\n>  test_done\n"},{"id":"328318","messageId":"CAGZ79kaycuiFuB1m0SiyKoZ6UyEBCMiipYXkavN+NNyCZaY1=Q@mail.gmail.com","threadId":"46612","inReplyTo":"xmqqlgleup78.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2] add test for bug in git-mv for recursive submodules","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-09-18T20:03:32Z","receivedAt":"2017-09-18T20:03:39Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":">> Took a little while but here is a more clean patch creating individual\n>> submodules for the nesting.\n>>\n>> Cheers Heiko\n\nThanks for writing this test!\n\n>\n> Thanks.  Stefan, does this look good to you now?\n\nYes, though there are nits below.\n\n> It is not quite clear which step is expected to fail with the\n> current code by reading the test or the proposed log message.  Does\n> \"mv\" refuse to work and we do not get to run \"status\", or does\n> \"status\" report a failure, or do we fail well before that?\n\ngit-mv failing seems like a new possibility without incurring\nanother process spawn with the new repository object.\n(Though then we could also just fix the recursed submodule)\n\n> The log message that only says \"This does not work when ...\" is not\n> helpful in figuring it out, either.  Something like \"This does not\n> work and fails to update the paths for its configurations\" or\n> whatever that describes \"what actually happens\" (in contrast to\n> \"what ought to happen\", which you described clearly) should be\n> there.\n>\n> Description on how you happened to have discovered the issue feels a\n> lot less relevant compared to that, and it is totally useless if it\n> is unclear what the issue is in the first place.\n>\n>>  t/t7001-mv.sh | 25 +++++++++++++++++++++++++\n>>  1 file changed, 25 insertions(+)\n>>\n>> diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh\n>> index e365d1ff77..cbc5fb37fe 100755\n>> --- a/t/t7001-mv.sh\n>> +++ b/t/t7001-mv.sh\n>> @@ -491,4 +491,29 @@ test_expect_success 'moving a submodule in nested directories' '\n>>       test_cmp actual expect\n>>  '\n>>\n>> +test_expect_failure 'moving nested submodules' '\n>> +     git commit -am \"cleanup commit\" &&\n>> +     mkdir sub_nested_nested &&\n>> +     (cd sub_nested_nested &&\n\nWe seem to have different styles for nested shell. I prefer\n\n  outside command &&\n  (\n      first nested command here &&\n      ...\n\nas that aligns indentation to the nesting level. I have seen\nthe style you use a lot in the  test suite, and we do not have\na guideline in Documentation/CodingGuidelines, so I do not\ncomplain too loudly. ;)\n\n\n>> +             touch nested_level2 &&\n>> +             git init &&\n>> +             git add . &&\n>> +             git commit -m \"nested level 2\"\n>> +     ) &&\n>> +     mkdir sub_nested &&\n>> +     (cd sub_nested &&\n>> +             touch nested_level1 &&\n>> +             git init &&\n>> +             git add . &&\n>> +             git commit -m \"nested level 1\"\n>> +             git submodule add ../sub_nested_nested &&\n>> +             git commit -m \"add nested level 2\"\n>> +     ) &&\n>> +     git submodule add ./sub_nested nested_move &&\n>> +     git commit -m \"add nested_move\" &&\n>> +     git submodule update --init --recursive &&\n\nSo far a nice setup!\n\n>> +     git mv nested_move sub_nested_moved &&\n\nThis is the offending command that produces the bug,\nas it will break most subsequent commands, such as\n\n>> +     git status\n\ngit-status is one of the basic commands. Without\nstatus to function, I think it is hard to recover your repo without\na lot of in-depth knowledge of Git (submodules).\n\nI wonder if git-status should complain more gracefully\nand fallback to one of --ignore-submodules={dirty, all},\nthat actually still works.\n\nMaybe we could introduce a new default mode for this\nflag, that is \"none-except-on-error\", though this sounds\nas if we're fixing symptoms instead of the root cause.\n"},{"id":"328465","messageId":"20170920134633.GA89070@book.hvoigt.net","threadId":"46612","inReplyTo":"CAGZ79kaycuiFuB1m0SiyKoZ6UyEBCMiipYXkavN+NNyCZaY1=Q@mail.gmail.com","subject":"Re: [PATCH v2] add test for bug in git-mv for recursive submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-09-20T13:46:33Z","receivedAt":"2017-09-20T13:46:49Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Sep 18, 2017 at 01:03:32PM -0700, Stefan Beller wrote:\n> >> Took a little while but here is a more clean patch creating individual\n> >> submodules for the nesting.\n> >>\n> >> Cheers Heiko\n> \n> Thanks for writing this test!\n\nNo worries. :)\n\n> > Thanks.  Stefan, does this look good to you now?\n> \n> Yes, though there are nits below.\n> \n> > It is not quite clear which step is expected to fail with the\n> > current code by reading the test or the proposed log message.  Does\n> > \"mv\" refuse to work and we do not get to run \"status\", or does\n> > \"status\" report a failure, or do we fail well before that?\n> \n> git-mv failing seems like a new possibility without incurring\n> another process spawn with the new repository object.\n> (Though then we could also just fix the recursed submodule)\n\nIt is mv that fails to update everything necessary when using it with\nrecursively nested submodules. So the git-mv command does not report a\nfailure here. As an interim fix it could maybe report an error when\nencountering nested submodules but the real fix would be to teach it to\nrecursively spawn the appropriate git-mv commands.\n\n> > The log message that only says \"This does not work when ...\" is not\n> > helpful in figuring it out, either.  Something like \"This does not\n> > work and fails to update the paths for its configurations\" or\n> > whatever that describes \"what actually happens\" (in contrast to\n> > \"what ought to happen\", which you described clearly) should be\n> > there.\n> >\n> > Description on how you happened to have discovered the issue feels a\n> > lot less relevant compared to that, and it is totally useless if it\n> > is unclear what the issue is in the first place.\n\nSorry about being a bit brief here. How about dropping that information\nhow I discovered the bug then and change the commit message to something\nlike this:\n\n    add test for bug in git-mv for recursive submodules\n\n    When using git-mv with a submodule it will detect that and update\n    the paths for its configurations (.gitmodules, worktree and\n    gitfile). This does not work in case it encounters nested\n    submodules. In that case it only updates the configurations for the\n    submodule directly underneath the superproject and fails to update\n    the paths for the submodules nested more deeply. This in turn leads\n    to the symptom that git status reports that it can not chdir to the\n    nested submodule in its old location.\n\n    Lets add a test to document.\n\n?\n\n> >>  t/t7001-mv.sh | 25 +++++++++++++++++++++++++\n> >>  1 file changed, 25 insertions(+)\n> >>\n> >> diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh\n> >> index e365d1ff77..cbc5fb37fe 100755\n> >> --- a/t/t7001-mv.sh\n> >> +++ b/t/t7001-mv.sh\n> >> @@ -491,4 +491,29 @@ test_expect_success 'moving a submodule in nested directories' '\n> >>       test_cmp actual expect\n> >>  '\n> >>\n> >> +test_expect_failure 'moving nested submodules' '\n> >> +     git commit -am \"cleanup commit\" &&\n> >> +     mkdir sub_nested_nested &&\n> >> +     (cd sub_nested_nested &&\n> \n> We seem to have different styles for nested shell. I prefer\n> \n>   outside command &&\n>   (\n>       first nested command here &&\n>       ...\n> \n> as that aligns indentation to the nesting level. I have seen\n> the style you use a lot in the  test suite, and we do not have\n> a guideline in Documentation/CodingGuidelines, so I do not\n> complain too loudly. ;)\n\nYeah we have some different styles it seems ;) So here some reasoning\nbehind my style:\n\nI actually would agree on your style if 'first nested command' was any\narbitrary command but when I use my style it is always when I use a\nnested shell for changing into some directory, doing something there and\nthen being able to return to the previous directory by closing the nested\nshell. So for me the 'cd somewhere' belongs to the brackets similarly\nlike a condition definition belongs to the if it is used with.\n\n> >> +             touch nested_level2 &&\n> >> +             git init &&\n> >> +             git add . &&\n> >> +             git commit -m \"nested level 2\"\n> >> +     ) &&\n> >> +     mkdir sub_nested &&\n> >> +     (cd sub_nested &&\n> >> +             touch nested_level1 &&\n> >> +             git init &&\n> >> +             git add . &&\n> >> +             git commit -m \"nested level 1\"\n> >> +             git submodule add ../sub_nested_nested &&\n> >> +             git commit -m \"add nested level 2\"\n> >> +     ) &&\n> >> +     git submodule add ./sub_nested nested_move &&\n> >> +     git commit -m \"add nested_move\" &&\n> >> +     git submodule update --init --recursive &&\n> \n> So far a nice setup!\n\nThanks.\n\n> >> +     git mv nested_move sub_nested_moved &&\n> \n> This is the offending command that produces the bug,\n> as it will break most subsequent commands, such as\n\nYes.\n\n> >> +     git status\n> \n> git-status is one of the basic commands. Without\n> status to function, I think it is hard to recover your repo without\n> a lot of in-depth knowledge of Git (submodules).\n> \n> I wonder if git-status should complain more gracefully\n> and fallback to one of --ignore-submodules={dirty, all},\n> that actually still works.\n> \n> Maybe we could introduce a new default mode for this\n> flag, that is \"none-except-on-error\", though this sounds\n> as if we're fixing symptoms instead of the root cause.\n\nI think we should rather fix the root cause. For me git-mv is actually\nbreaking the repository and as described above one possible interim\nsolution for me would be for 'git-mv' to error out and tell the user\nthat it does currently not work on recursively nested submodules.\n\nCheers Heiko\n"}]}