Hi the submodule will come back there if you open a file in the submodule, but yes we changed the settings to match what vscode does and only show the main repo until you do anything in the submodules
This does not restore original behavior. These settings do not work. Original behavior is you open a project, and immediately you open the git panel and can see all submodules IMMEDIATELY, with 0 config or settings changes. The absolute best we can do after this update is enable “git.detectSubmodules” and ignore “git.autoRepositoryDetection” (Since it does the same behavior regardless of what it is set too). Then with that you can get it to where you then have to go and navigate to EACH submodule, and open a file and it will show finally in the git panel for that specific submodule, but I do not know a single person with submodules that wants it to work like that…
No idea why you guys decided to arbitrarily change this for no reason when no one was even asking, but would be greatly appreciated if you guys could revert it back to the old behavior.
I just put these settings back and restarted cursor and saw all of our submodules show up immediately as it used to be, did you restart cursor after changing them?
Yes changing “detect submodules limit” fixes it. I updated my post in another bug report post to include this fix, but “detect submodules limit” is not documented anywhere regarding this issue, by Cursor, nor VSCode.
The main issue itself I think stems from the fact that after the update, this value seems to be force set to 0 for some reason regardless of its previous value, and then there is just 0 mention of this setting anywhere. Even googling this setting you get basically 0 docs for it, let alone anything in the recent VSCode or Cursor update notes to indicate why this was changed.
Ok next patch release will revert the submodules limit config change, verified that all you have to do is check “Git: Detect submodules” and they will all show up (after restart)