I'm using the builtin setting sync with vscode (not the extension), I've successfully synced, yet I do not see the actual files anywhere through github. Do these files exist somewhere that is accessible through github?
From what I can tell the files are not accessible through github, obviously they are at the root of the repo in .vscode/, but I'd love to actually see the backed up version.
The way I handled this with vim was to add a source command in the .vimrc, then link that to it's own github repo.
I guess I'll have to just trust that github and vscode have it handled
Is it possible to share the ignore.conf with all clients via the shared configuration repository plastic-global-config ? I can't seem to find any documentation regarding that special repo except for custom extension configurations.
The "client.conf" is a client side configuration file. The user-global ignore file is a file that affects to all the machine workspaces and not only a specific one.
But as a client config file, if you want to share this file with the different Plastic users, I would recommend you to commit it into your repository. This way all the developers will be able to download it. If you prefer, to independently customize the ignored files, keep it as private (local not committed file).
Is the .vscode folder meant to be committed to source control?
In a fresh project, the folder is empty, except the settings.json file. What kind of things would go into this folder? Is it machine-specific, developer-specific like the .vs folder and thus not be committed? Or should all developers share this folder and thus it should be committed?
The comment at the top of the file .vscode/settings.json states:
// Place your settings in this file to overwrite default and user settings.
{
}
This seems to imply that the folder should contain project-specific settings and thus be included in source. Also, this post on UserVoice seems to imply some typings would go in there, also suggesting that it should be committed.
Check in the .vscode folder if you want to share settings, task configuration and debug configuration with the team. I think generally it makes sense to share settings (e.g. whitespace vs tabs) with the team if you want to enforce settings in a team. We in the VS Code team share debug and task specific settings as well because we want our team to have the same set of debug targets and task targets for VS Code.
Btw you do not need to have a .vscode folder in your project for settings. You can also configure settings on a user level.
Commit some files in .vscode folder
Recommendation is to generally exclude .vscode folder, but leave select JSON files that allow other developers to recreate shared settings.
Examples of settings to include:
Language specific test configurations to run the test suite(s) (settings.json)
Extension settings for linters and code formatting tools to enforce the language rules used in this repo (settings.json)
Run and debug configurations (launch.json)
Shared tasks - if managed with VS Code (tasks.json)
Note that some settings can be stored in the user settings or workspace file, or transferred to it from the .vscode folder. See below.
Sample .gitignore code
Here are the settings, as suggested at https://gitignore.io. You can search for "VisualStudioCode" there to get the latest recommended .gitignore file. I use this website as a starting point for .gitignore for most of my new repos:
# Created by https://www.gitignore.io/api/visualstudiocode
# Edit at https://www.gitignore.io/?templates=visualstudiocode
### VisualStudioCode ###
.vscode/* # Maybe .vscode/**/* instead - see comments
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
### VisualStudioCode Patch ###
# Ignore all local history of files
**/.history
# End of https://www.gitignore.io/api/visualstudiocode
In the above .gitignore file, the .vscode/* line (note: some debate on whether the * should be included - see comments; .vscode/**/* may be better to ignore nested folders as well) says to exclude everything in the .vscode folder, but then the !.vscode/a_specific_file lines tell git to "not" ignore some specific files in that folder (settings.json, launch.json, etc.). The end result is that everything is excluded in the .vscode folder except for the files specifically named in one of those other lines.
Other Factors
Including the .vscode folder in your repo doesn't actually hurt anyone that uses a different IDE (or text/code editor).
However, it may cause issues for other people using VS Code, or some of the settings may not load properly, if these files include generic settings that require something specific to your environment - like the absolute path the repo is installed in. The key is to avoid saving settings that are custom to your local environment, only sharing those that can (or, in the case of this repo, should) be used by everyone.
For example, if IDE setting files have absolute paths to the repo or any files/libraries, etc., then that is bad, don't share. But if all the references are relative, then they should work for anyone using the repo (although, be careful about path specification differences between Windows/Unix..).
About User, Workspace, and Folder settings
Note: the settings files in the .vscode folder are generally updated when you make changes to the folder version of the settings - but this appears to depend on how individual extensions are coded, because I've run across multiple exceptions to this rule.
If you make changes to the user settings, they are usually stored elsewhere (location depends on OS settings, usually in a home directory).
If you make changes to the workspace settings, they are usually stored in the *.code-workspace file that you are currently using. If you don't have a workspace (you directly opened a folder instead), then they will likely go to the .vscode folder, but, overall, this may depend on the extension that owns the setting anyway.
So, you should generally put custom settings for your personal PC into the user settings, and put generic settings into the workspace or folder settings.
Between commit/ignore there is third clever option: commit with .default suffix.
For example you can add settings.json to .gitignore, and commit settings.json.default, much like it is common practice (in my team) with .env files.
I took this advice from video Commit editor settings to version control? by Mattias Petter Johansson
never commit .vscode/settings.json - with the weird exception of search.exclude . If you really need to, be very careful of putting only settings particular of your project that you want to enforce to other developers.
for validation, formatting, compilation use other files like package.json, .eslint, tsconfig.json, etc
The only .vscode that makes sense to include are complex launch configs for debugging.
Be careful, there could be a third party extension in your system that could put private information there !
What you can't do is copy & paste the whole settings.json contents file to .vscode/settings.json. I'm seeing some people doing this and committing the file is an atrocity. In that case you will not only break others workspace but worst, you will be enforcing settings to users that you shouldn't like aesthetics, UI, experience. You probably will break their environments because some are very system dependent. Imagine I have vision problems so my editor.* user settings are personalize and when I open your project the visuals change. Imagine I have vision problems s I need to personalize user editor.* settings to be able to work. I would be angry.
If you are serious don't commit .vscode/settings.json. In general, settings that could be useful for a particular project like validation, compilation, makes sense but in general you can use particular tools configuration files like .eslint, tsconfig.json, .gitignore, package.json. etc. I guess vscode authors just added the file for simplifying newcomer experience but if you want to be serious don't!
The only exception, and in very particular cases could be search.exclude
Why not just looking at the practice, other than the arguments around here?
One of the biggest project that keeps .vscode I found so far is Mozilla Firefox.
It looks like the Firefox team shares their common tasks and recommended extensions.
So I guess it is not a bad idea to keep .vscode, as long as you know what you are doing.
I will update this post when I see other big projects that shares .vscode.
Same as other answers: no.
As an illustration, consider the approach chosen by Git 2.19 (Q3 2018), which adds a script (in contrib/) to help users of VSCode work better with the Git codebase.
In other words, generate the .vscode content (if it does not yet exist), don't version it.
See commit 12861e2, commit 2a2cdd0, commit 5482f41, commit f2a3b68, commit 0f47f78, commit b4d991d, commit 58930fd, commit dee3382, commit 54c06c6 (30 Jul 2018) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 30cf191, 15 Aug 2018)
contrib: add a script to initialize VS Code configuration
VS Code is a lightweight but powerful source code editor which runs on your desktop and is available for Windows, macOS and Linux.
Among other languages, it has support for C/C++ via an extension, which offers to not only build and debug the code, but also Intellisense, i.e. code-aware completion and similar niceties.
This patch adds a script that helps set up the environment to work effectively with VS Code: simply run the Unix shell script contrib/vscode/init.sh, which creates the relevant files, and open the top level folder of Git's source code in VS Code.
Okay, this may seem pretty late, but if you're finding it difficult to ignore .vscode/ without including any sub-file, you could just ignore the directory:
.vscode/
and then manually track the file you want:
git add -f .vscode/launch.json
The -f adds files even when they're ignored. Once Git sees changes to .vscode/launch.json you'll be prompted to commit them just like any other file.
this actually worked for me, caused i experience the same issue, trying to ignore the .vscode/ path, without including a sub-file settings.json
A simple way to keep your settings without commit it in your project git repository is creating a workspace and add folder into it.
When do you create a workspace, you need to save a file code-workspace. This file contains custom settings, just save this file out of the git repository and will be free to add .vscode into .gitignore file.
The answer is "NO",because .vscode folder is for this editor and you should't push these personal settings to repo in case of confusing others ,so you can add it to your project's .gitignore file to ignore the changes
I have already used some VCS like CVS, SVN and Git. One feature that I am missing cannot be found anywhere.
There are files which I would like to have in the repository but every user should have its own. So when you checkout you get a default of that file and that commit your changes only for yourself.
Why do I want this? There are some files like configuration where I would like to have a default version in the repository (e.g. for building releases or a starting base for new team members) but the changes to that file are only relevant to a certain developer (or working copy) because it will contain paths only valid for that developer/working copy.
Currently when I do not add this files:
- I miss them when creating a new working copy or exporting for a release build
- Have no history which changes I might have done for myself for experimenting
Currently when I add this files to the repository:
- I might never commit them so I have a default in the repository but my file is always flagged "changed". In SVN I can add it to the "ignore-on-commit" changelist to improve a bit.
- I might loose my very own changes of a difficult configuration file (data crash, laptop theft, etc.)
Is there a VCS capable of this? Do SNV or git support something regarding this I might have overseen?
If I understood and decomposed your task correctly
"Have a set of default templates of something, which are starting point of per-user customization and these customized versions must be stored separately and be accessible only by responsible person"
you can use this workflow (draft, subject of modifications and corrections), Subversion based for simplicity and transparent management (strong point of any CVCS really)
Subversion repository
Each user of repo have own predefined path inside repository-tree (with common path-pattern for manageability and easy automation of processes)
One special admin-only managed path also exist, not accessible by ordinary users
Our tree may seems like this (where Repository dir is a root of repository)
z:\>dir /s /B
z:\Repository
z:\Repository\Users
z:\Repository\Template
z:\Repository\Users\Alpha
z:\Repository\Users\Bravo
For every user-path we use Path-based Authentication, which provides access for every and each user only to own subtree in repository,
Template contains (as name assumes) templates stub for all user's documents
Adding new users to repo, obviously, becomes simple and easy automated task:
svn copy Template into new user's dir
add rw permissions for created location for user in authz-file
tell user URL of his personal tree in repo
I don't think the VCS is the problem here. It looks like if you have a file whose contents are dependent on the local environment, you should auto-generate it with a script. This way, you ignore the generated file, but version the script and each developer still gets a perfectly valid copy of the config files at run time. This is the same approach that is used, for example, with user specific IDE settings: .suo files on Visual Studio for example.
Update:
If you specifically need a set of defaults, then the solution is this:
Add the defaults to the repository.
Each dev works in their own branch. This way, they can version the
changes to the config files.
When re-basing onto master and/or merging, the devs simply never
merge their customized configs.
You can always set up a hook to check if the default config has been modified, and if so, maybe email the dev. You simply view such a commit the same as you would view a commit that does not compile.
Devs are smart. Sure, they make mistakes. But never under-estimate the power of some simple communication.
Of course, when the default configs do get overwritten with the customized ones of Dev X, then you use the powers of git to fix that commit immediately.
I have a setup as follows.
A private repository at bitbucket where I keep the 'master' repository.
A repository on my server which acts as the 'live' website.
A repository on my laptop which acts as my working copy.
My process is as follows. I make a change to a file in my local repository. I commit these locally. I push these changes to bitbucket. I then pull these changes from my bitbucket to the webserver.
The problem that I have however is that my local copy utilizes different configuration settings for databases, paths etc, ergo what I want is my 'config.php' file at bitbucket to contain the server settings, and the config.php on my local host to contain local settings.
I believe this can be achieved with .hgignore but i have had no success researching.
The problem i encounter is that i make my server settings file, push it to bitbucket, 'forget' the file in my local repository, create a .hgignore, and then recreate the file. However when i 'forget' the file TortoiseHG notices and asks me to commit the change to bitbucket....
Any ideas would be greatly appreciated.
Thanks
Additional Points.
Following the advice below I have developed a setup as follows:
I have my local repository on my laptop where i do my edits.
I have bitbucket which is essentially the 'main' repository - if any other developers join the team they clone this.
I have my live repository on my web host.
On my live repository I have a .hgignore file whichs ignores the respective config files.
As such when I do hg pull from my host, it pulls the repository as is with the localhost configuration files, but when i type hg update (to the live working copy), these files are ignored/not updated.
Could someone clarify as to if i have understood this correctly, and as to whether this is a suitable way of achieving what I want?
Thanks
.hgignore only ignores files if they are not versioned already, so I don’t think your idea in the question will work.
The common approach regarding local configuration is generally a variation on the same theme, like of one of the following:
Do not check in the config.php at all. You can check in a config.example.php with the most common settings, and document in the README that users have to copy it to config.php and then edit it.
Put any shared settings in config.php, and add an include statement to point to an unversioned file with settings specific to the machine, e.g. config.local.php. You can also provide an config.local.example.php-file for this.
Like 2, but the config.php contains all default settings and the local file has the ability to override them.
Check in a config.dev.php and config.server.php-file containing the settings for both environments, and then have an unversioned config.php which includes one of the above files. Advantage is that the configurations themselves are versioned and you can update them.
Which of these variations to pick, or whether you make another variation, depends on your environment.
The basic idea for working with version control and different configuration files is always the same, but I don't know enough PHP to give a detailed answer how you can do this in PHP.
I answered a similar question for .net/Visual Studio a few months ago, so I'll just give you the link to this answer and try to describe the basic idea again, but this time language-agnostic:
For your use case, the basic idea is to have two config files in the repository, one with your local data and one with your server data, for example like this:
config.local.php
config.server.php
The "real" config.php is not in the repository, and it should be in .hgignore, so it never will be in the repository either.
After pulling, you need to run something that copies one of these files (the "correct" one depending on the current environment, local or server) to config.php.
And exactly this last part is the part that I can not answer in detail, because I don't know how to do that in PHP and/or on a web server because I'm a .net/Windows guy.
As far as I know, deploying a PHP site is just copying the files on the web server, so there is no "build/compile" step where the copying/renaming of the config file could be done (where I would do it in .net). Correct me if I'm wrong...
EDIT:
Thomas, I'm not sure if I understood your edits correctly. Your "local" repository on your laptop and your "live" repository on your webserver are basically clones of your "main" repository on Bitbucket, correct?
If yes, are you saying that you have different .hgignore files in the different clones?? That's the part that confuses me.
No matter how you actually do it in the end (there are several possibilities to deal with configuration files, see below), the .hgignore file should be the same in all clones of your repository.
So all your repositories (no matter which clone on which machine) should all contain the same configuration file(s).
Then, you only need to make sure that different configurations are used in different environments. There's already an excellent list of different ways to achieve this in Lauren Holst's answer, so I'll just point you there.
As Laurens Holst already said, we can't tell which of these ways is the best for you - it depends on your environment.
You might want to check here. If both the config file and .hgignore are commited, the .hgignore will have no effect. You could also add a domain check conditional:
$domain = $_SERVER['HTTP_HOST'];
if ($domain=="localhost") {
//local copy config
}
else if ($domain=="yourdomain.com") {
//webserver config
}