Closed OldStarchy closed 6 years ago
managed by composer
I'm assuming you are having this issue with the vendor
"subfolder", where all the composer plugins (which are basically git repos) are stored? If this is the case - these are not submodules : they are simply repositories within your root repository (which is very different than a git submodule).
Why am I saying that? Well, VSCode does not put repositories found in gitignored subfolders, which your vendor
is supposed to be. The vendor
folder is like the place for your libraries and you don't want to put that in your root repository (it often causes alot of synching problems - ghost log files every modifications within the vendor
folder).
Basically, if this is the situation you're in, make sure your vendor
folder is ignored in your .gitignore
project file (example taken from default laravel's .gitignore
file) and if you already created a commit with the vendor in your repo and don't know why the vendor
folder is still not ignored after adding its entry in the gitignore file, read this answer from SO.
Of course, this solution is based off many assumptions on my part : the confusion about submodules, non-ignored library folder, etc. If this does not apply to you, I don't really how I'll be able to help any further.
All in all though, the idea of not tracking the changes in a submodule is IMO a regression (even as a setting) as it's actually a big feature of Git, and having it integrated in VSCode is a really neat utility. If you are having problems with them, it's usually because you aren't using them correctly or because your project is not setup correctly.
Given that I also work from a network drive 99% of the time, nearly every file in those directories are listed as modified due to filemode 'changes' and the file explorer gets littered with "modified" annotations.
This should go in another issue, I think it's a valid one that should be looked that (didn't search much if an issue was already opened for that one though : maybe #13665?).
EDIT :
Spoke too soon and misunderstood your request it seems, there's already a git.detectSubmodules
, just realized that. In that regard though, it might be a duplicate of #50165, but I won't say it is definitely after my huge mistake of that big comment :)
The second part of the network drive is still valid though, it should go in its own issue.
Even though you struck out your comment, I want to clarify, yes there is a vendor
folder, but there's a lot of other folders that each contain separate repos, not git submodules. I work with SilverStripe 3.x where the required modules are copied to their own folders next to vendor
.
As for the working on the network drive, I don't think its something that VSCode should really have to deal with, as the problem is caused by the fact that we run all our composer commands via SSH on the share server (this makes sure the correct modules are installed for the servers version of php) but we do all our git work over the samba share. So the initial checkout would see the files locally with one set of permissions, and working from windows over samba, the files would appear with slightly different permissions. Also, it seems that composer (or git?) by default configures each repo it clones with core.filemode true
, so setting git config --global core.filemode false
doesn't take any effect as its overridden in each individual repository.
Regarding VSCode ignoring folders listed in the .gitignore
, as I mentioned, a large number of our projects are held in SVN, and due to forces outside of my control, in those projects we also check in all the composer-required modules and folders (even vendor
). So even if there is an equivalent .gitignore
detection for SVN, it unfortunately wouldn't be effective in this case.
Added two new possible values for git.autoRepositoryDetection
: subFolders
and openEditors
. This will let you configure git.autoRepositoryDetection = "openEditors"
and disable subfolder detection.
Thanks @joaomoreno that works well.
There are a number of issues regarding git submodules, and I'm sure in that situation
git.detectSubmodules
would work perfectly fine.I often find myself in a situation where the root directory is an SVN checkout (or not under any SCM) and 20 out of the 21 immediate subfolders are git repositories (managed by composer). With both
git.detectSubmodules: false
andgit.autoRepositoryDetection: false
, the Source Control tab opens every one of those folders, which I find to be very messy. (Looking at the source for the functionality behind those options, I can see why they don't do what I had hoped). Given that I also work from a network drive 99% of the time, nearly every file in those directories are listed as modified due to filemode 'changes' and the file explorer gets littered with "modified" annotations.The closest issues to this that I could find are #10450 (basically the opposite of my request), #43951 (not really related), and #47348 (close, but no cigar)
I'd like a setting such as
git.detectSubfolderRepositories
that I can set tofalse
to disable this detection. Additionally, it would also be useful to manually add subfolders back into the Source Control tab. I don't see a way to do this after doing right click -> "Close Repository". Nicer yet, the ability to remember which repositories were opened / closed when reopening the workspace folder.