Every time I open a repo with a lot of submodules on VS Code, I get a pop-up message like:
The 'rust-devel' repository has 15 submodules which won't be opened automatically. You can still open each one individually by opening a file within.
Is there any way to disable this?
I didn't find a way to disable this warning. However there is a workaround: By increasing the Git: Detect Submodules Limit setting to a value higher than the number of submodules, the warning is not shown.
For example, this sets the limit to 30 via the VS Code settings.json file:
{
"git.detectSubmodulesLimit": 30
}
edit settings.json:
"git.detectSubmodules": false,
"git.detectSubmodulesLimit": 9999
The first one avoids the auto-detection, the second one gets rid of the warning. credit Probably best to set more reasonable in case 9999 may slow your machine. Couldn't seem to find any reasoning why the default is 10.
also see vs code defaults:
// Controls whether to automatically detect git submodules.
"git.detectSubmodules": true,
// Controls the limit of git submodules detected.
"git.detectSubmodulesLimit": 10,
Related
I use VS CODE for version control (using git).
Every time I had a conflict, VS CODE showed me with a layout where I could see all the changes in one window:
However, with no advice, it change to a weird 3 windowed design where I can't understand anything.
Does someone know how can I go back to the first design?
Go to VS Code settings
Untick the Git: Merge Editor setting
Now you should be able to see the previous merge layout.
This feature (3 way merge editor) can be enabled by setting git.mergeEditor to true and will be enabled by default in future releases.
You can set it back to false to go back to the previous design as you want.
This new 3-way merge editor seems to have a terrible UX issue. For me simply switching to merge editor to 'false' doesn't work as below:
git.mergeEditor = false
After this editor completely stopped showing me any merge conflict line.
I have to finally do like this to revert back to original merge conflict view.
"diffEditor.codeLens": true,
"git.mergeEditor": false
Hit ctrl+shift+p to open command pallet and open the settings json by typing Preferences: Open User Settings (JSON) (or start typing 'settings' and this will come up)
In the main JSON object add "git.mergeEditor": false (insert comma beforehand if needed)
Hit ctrl+shift+p and type Developer: Reload Window to reload the windo.
The old type of merge editor should be back.. but you may need to wait a minute to get the full UI back (on my machine, the accept incoming buttons etc. didn't come back for a little).
Update 2023 in case the conflict UI has crashed/not displayed
When you rebase a file with embedded conflicts within conflicts VScode's in- file-conflict-display(blue/green UI) might glitch due to too-many git markers present, rendering merge impossible without CLI.
Apply workaround by enabling and switching to 3 way conflicts window.
enable merge editor (by searching the settings or modifying vscode config file locally)
use vscode's merge display by going to Source Control tab then clic the file with ! exclamation mark before the name of the file
solve the maximum number of conflict using the new 3 windows conflict UI (remember current and incoming are inverted in case of rebasing)
go back to normal file UI and the classic in-file-conflict-UI (green/blue) should be back online
finally git add . && git rebase --continue && :wq (vim) in case of rebase to pass to the next commit to handle.
Rule of Thumb: Remember to always create a temporary local branch of your feature before merging/rebasing your feature branch before PR. This will be used as backup to keep the design intent in mind. Then always run code(and lint) to check for obvious typos/merge artifacts (ie these git flags or unclosed loops/functions).
I noticed that the VSCode editor sometimes mark/track changes (https://imgur.com/a/u4U2tdc where there's a blue mark next to line 16 to indicate a change) and sometimes it doesn't, and today it's not tracking changes for some reasons, and I am not sure what's causing the issue.
Could someone advise how to debug this issue?
This is controlled by the setting scm.diffDecorations. By default, it should be set to all:
Check this setting. Additionally, new files that you just added can't show these differences, because it (Git) has nothing to compare it to yet. The same can be said for untracked files.
In November 2020 VSCode got a PR #104923.
It made it possible to click in the scrollbar in the editor, to move 1 page at a time, in stead of jumping somewhere.
So the normal scrollbar click behaviour in windows.
I have searched the settings and online everywhere, but I have no idea where and how, I can set the parameter to true.
About the parameter itself:
In this PRT it says on sep 16 2020:
"I made the setting editor.scrollbar.gutterClickMovesByPage default to false"
And near the end it says:
"Rename option to scrollByPage".
So what is its name, and where can I find it.
Thanks!
(I use VSCode version 1.55.0)
On Linux, adding in ~/.config/Code/User/settings.json:
{
"editor.scrollbar.scrollByPage": true
}
seems to have done the trick for me. Nowhere documented indeed and https://github.com/microsoft/vscode/issues/43564 still shows unreleased, while commits did got tagged with release versions. It took me some time today to figure out how to enable this.
EDIT: You need to restart VSCode in order to have this option considered.
To find the settings.json file's location: on Linux vscode, after opening the Settings, just hover over the User tab in the first line and it shows the file location. Probably that's the same on other platforms.
Option does not show in the list of known and documented options from UI.
That's bad that they left the jumpingbars by default instead of the scrollbars. When using a touchpad and not a mouse, that's really frustrating to have these jumpingbars.
Yesterday a few files in one of my folders(git repository) have turned green and have a number next to them like so:
Can anybody tell me what this means? The repository is synced and up to date and that was the only possible thing I could assume it meant.
Thanks!
Those are the file explorer's problem decorations. They use colors and indicators to show which files have problems associated with them. The green here indicates there is a warning in the file, and the 1 indicates that there is one warning.
You can disable these by setting: "problems.decorations.enabled": false
This works well if you are using git. Doing a simple commit to your repo will take the warnings away.
I am using SVN external to VS code for a project and it became quite frustrating seeing files with issues and 'untracked'.
If anyone else in in this boat, set "git.enabled": false in your vs code workspace settings.
I've been searching for this. I've finally figured out the answer.
Go to File>Preferences>Settings (also ctrl + ,)
Go tot he "Workspace" tab > Git. Set Decorations Enabled: Off
I want to commit my works. But when I want to see what I changed and wrote them into commit message, I saw some of my changes won't show.
What is the problem?
Change The Maximum Lines And Size In Options
Tools > Options > Diff
Change Max Diff Line Count
And
Change Size Limit (Text)
I'm adding this answer as another possible cause of SourceTree "only showing the change history for a single file". This was annoying me for quite a while. No settings changes would display more than one file. THEN, I realised that the commit summary is actually a panel which slides up over the file list. ZOMG.
Make sure your filter is setup correctly:
For me the filter bugged out and while the main text said "Pending files", the dropdown had nothing selected.
Size Update For the latest ScourceTree
ScourceTree -> Preferences -> Diff -> Size limit(text)
Make sure that you copy the last version of your project, the one that you want to commit, to the directory of your repositories that you set for SourceTree. Replace the old project with the new one then open SourceTree
Open SourceTree, click commit, select all the files that you want to commit, which will probably be all the files you see (becuase SourceTree shows the changed files after you click commit).
On the Puush button on the top you'll se a red notification icon which means that you didn't push the last commit. Once you do that, your changes must be visible on BitBucket and SourceTree
Another possible reason:
Make sure Ignore whitespace in the diff view is not enabled.
If it is not a Pending issue or an options issue mentioned above, make sure Mercurial wasn't inadvertently checked if you're using it with Git. It will manifest in a similar way. If so, you're going to need to deinstall & re-install.