New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect git repositories under ignored paths #41565
Comments
What happens if you create a workspace and add the root folder and those extra1 and extra2 folders to it? |
No git features work, no matter if you edit the file from within the main folder or others. |
I ran into this exact issue when setting up root folders in a workspace. The only work around right now is to Take the following folder structure for reproducing the issue:
The
Steps to reproduce when adding the subfolder to the workspace:
Steps to reproduce when adding the root to the workspace:This resolves the issue
In this process the changes to the sub-folder are still reflected in the Source Control sidebar and both Git repos are listed under "Source Control Providers." The order of the added directories matters.I'm not sure if this is intendend functionality but this is what my investigation has pointed out. This doesn't work
This works
I'm not sure what the absolute solution should be but setting modifying the order of the paths in the workspace config file is my current solution. Hope this helps! Edit: Changed the solution in the top paragraph. Testing and debugging while writing up the issue is always fun haha. |
Interesting... In any case I guess when sub-gits exist in a project, those should get detected automatically, without the need of adding them to workspace, etc. |
I'm currently working on a project that's directly affected by this. |
+1 Dropped in to give this issue a little push. I'm waiting for a solution as @jrtashjian's workaround works but is not convenient in my situation. |
+1 |
I though listing the sub-folder in |
Any update on this? I sadly cannot rely on the workaround because many extensions expect the root folder to be the first folder in the workspace. |
I can confirm this is also an issue when you open a folder that is inside a git ignored folder. So to take the OPs example, if I open a brand new project and open |
Also affected by this, if a folder is ignored by the root .gitignore then it doesn't show up in source control even if it has it's own git repo. |
Just ran into this issue too. A common workflow when using the dependency/ package management tool zc.buildout is to have dependencies which are being developed as part of a 'parent' project checked out into a |
Same issue here. Even opening the |
I may have a workaround here hope it's helpful.
Tip: The Source Control view won't append any |
This works. Thank you! |
In the September 2022 release we have added support for detecting nested git repositories. I believe that this should address the feature request described in this issue. I will go ahead and optimistically close this issue as resolved but in case the newly added feature does not address your needs please feel free to reopen the issue. Thanks! |
@lszomoru no this hasn't been resolved, and I suspect that there are actually 2 things here being conflated with each other depending on who has commented. See this comment:
If i have an ignored folder, and that folder contains projects, when I open those projects, all files and folders are grayed out because of a parent folder that is outside the project. For example: There is a folder several levels up that cannot be seen in VSCode and is not a part of the workspace that is under a git ignore for a repo that is also not a part of the workspace, therefore everything is grayed out. Note this does not happen if the folder opened is the top level of a git repo. |
This is a feature request.
I work in several projects, mostly Docker-related, where I need to edit code inside git repositories that are ignored inside the main one.
Example file tree:
The reasoning behind this is an aggregated Docker project that includes sources from many unrelated places. Developing means mounting local code, changing it, and pushing code to all repos (the main one and the ones under
external_sources
, where we mainly need to open PRs for that), but deploying to production means building a different Docker image where we download and merge external code instead of copying it from localhost.Boilerplate apart, the feature request is to be able to find those subrepositories, even if they are untracked from the main one, and let the user use the full SCM interface (diffs, SCM section...) on them.
Right now, the diffs do not show because you are editing ignored code, and the SCM does not show these folders for the same reason.
I gues that now that multi-root workspaces are in, this shouldn't be so hard to achieve...
Thanks!
The text was updated successfully, but these errors were encountered: