Commit graph does not open for a sub-repo

[vacovnik]

Description

I have a repository hierarchy that looks somewhat like this:

root_repo/
    sub_1/
        sub_1_sub_1/
        sub_1_sub_2/
    sub_2/
    ...       

It happens that right after the fresh start of the development (VS Code freshly opened), I am not able to open a graph of a sub-repository.
Instead a graph of it parent's repo is opened.

A soon as I open a file from that repo in a VS Code editor, commit graph opens correctly.

The same goes if I want to switch to a different sub-repo from within a commit graph.
The list of available sub-repos contains only the ones for which at least one file was opened in VS Code editor.

GitLens Version

15.1.0

VS Code Version

Version: 1.90.1 (user setup)
Commit: 611f9bfce64f25108829dd295f54a6894e87339d
Date: 2024-06-11T21:01:24.262Z
Electron: 29.4.0
ElectronBuildId: 9593362
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Windows_NT x64 10.0.19045

Git Version

git version 2.36.1.windows.1

Logs, Screenshots, Screen Captures, etc

No response

[brenocandido]

I've had the same problem and fixed it by configuring the maximum scan depth for repositories. Set "git.repositoryScanMaxDepth" to the appropriate depth where your submodules are and their graph should show accordingly.

[vacovnik]

Hi!

Thank you for the proposal.
It solved the issue but it also exposes all repositories present in my build directory that are pulled by CMake's FetchContent which is not desired especially when you have multiple build directories for native and cross compilation.

VS Code is able to correctly identify all submodules, so I think the commit graph should also be able to.

[jkelroy]

Hello @vacovnik, as mentioned git.repositoryScanMaxDepth will show submodules in the Source Control (provided by VS Code, not GitLens), which allows you to open submodules in the commit graph. Are you having an issue with this?

It sounds like you are trying to not show submodules/directories that populate your build directory in Source Control correct? If so, have you tried using git.ignoredRepositories or adjusting the .gitignore?

[vacovnik]

Hi!

@jkelroy, I would say that git.repositoryScanMaxDepth will scan for repositories within the working directory, not submodules.
I think that git extension in the VS Code (Source Control) does it correctly:

• uses git.repositoryScanMaxDepth to find .git folders/files within the working directory,
• resolves .git/config to also show submodules of all repos, found by the scan.

Are you having an issue with this?

Yes. As stated above, VS Code resolves submodules and shows them. When I try to open the graph for e.g. submodule-in-submodule, I get it for mp. When I open a file from submodule-1, I get a graph for it. Until a file from submodule-in-submodule is opened. Then it works.

It sounds like you are trying to not show submodules/directories that populate your build directory in Source Control correct? If so, have you tried using git.ignoredRepositories or adjusting the .gitignore?

The way the Source Control in the VS Code works is in my opinion correct.
Imaginary example structure:

.git/
build/
    _deps/
        dep1-src/
            .git/
        dep2-src/
            .git/
build_target/
    _deps/
        dep1-src/
            .git/
        dep2-src/
            .git/
Ext/
    submodule1/
        .git
        Ext/
            submodule1_1/
                .git
    submodule2/
        .git

With git.repositoryScanMaxDepth=1, only the root repo will be discovered.
After that it gets resolved and also submodule1, submodule1_1 and submodule2 appear in the Source Control list:

root
submodule1
submodule2
submodule1_1

In case I would increase the git.repositoryScanMaxDepth enough, dep1-src and dep2-src would also appear once per every build directory.

So my conclusion would be that the GitLens extension is not resolving submodules recursively as the VS Code does.

[github-actions]

This issue needs more information and has not had recent activity. Please provide the missing information or it will be closed in 7 days. Thanks!

[vacovnik]

Hi!

I think I added quite some info. Is it not sufficient? If it is not clear, please ask what is not described in detail enough and I will try to explain it better.