Detect git repositories under ignored paths

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:

main-repo/
  .git/
  .gitignore # <-- Here we ignore the `external_sources` folder
  src/
    [files]
  external_sources/
    extra1/
      .git/
      [files]
    extra2/
      .git/
      [files]

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!

[jrtashjian]

I ran into this exact issue when setting up root folders in a workspace. The only work around right now is to not use workspaces and instead open each of the other root directories into their own window update the order of the paths in the workspace config file so that the sub-folders are listed before the root folder. It seems as though vscode doesn’t separate the .gitignore for each root folder.

Take the following folder structure for reproducing the issue:

project-folder/
    .git/
    .gitignore
    sub-folder-one/
    sub-folder-two/
        sub-sub-folder-one/
            .git/
            .gitignore
        sub-sub-folder-one/
            .git/
            .gitignore

The project-folder/.gitignore file contains the following line:

/sub-folder-two/*

Steps to reproduce when adding the subfolder to the workspace:

1. Open up Visual Studio Code.
2. Click “Add Folder to Workspace…” from the “File” menu.
3. Add project-folder/
4. Click “Add Folder to Workspace…” from the “File” menu again.
5. Add project-folder/sub-folder-two/sub-sub-folder-one/
6. Make a change within the project-folder/ and you’ll see the change reflected in the Source Control sidebar.
7. Make a change within the project-folder/sub-folder-two/sub-sub-folder-one/ and you won’t see any changes in the Source Control sidebar.

Steps to reproduce when adding the root to the workspace:

This resolves the issue

1. Open up Visual Studio Code.
2. Click “Add Folder to Workspace…” from the “File” menu again.
3. Add project-folder/sub-folder-two/sub-sub-folder-one/
4. Click “Add Folder to Workspace…” from the “File” menu.
5. Make a change within the project-folder/sub-folder-two/sub-sub-folder-one and you’ll see the change reflected in the Source Control sidebar.
6. Add project-folder/
7. Make a change within the project-folder/ and you’ll see the change reflected in the Source Control sidebar.

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

{
    "folders": [
        {
            "path": "./"
        },
        {
            "path": "./sub-folder-two/sub-sub-folder-one"
        }
    ],
    "settings": {}
}

This works

{
    "folders": [
        {
            "path": "./sub-folder-two/sub-sub-folder-one"
        },
        {
            "path": "./"
        }
    ],
    "settings": {}
}

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.

[yajo]

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.