search

gitkraken / vscode-gitlens

Supercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more
http://gitkraken.com/gitlens
Other
9.04k stars 1.35k forks source link

Commit graph does not open for a sub-repo #3360

Open vacovnik opened 5 months ago

vacovnik commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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?

Screenshot 2024-06-26 at 5 14 15 PM

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 commented 5 months ago

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:

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[bot] commented 4 months ago

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 commented 4 months ago

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.