How do I get rid of these 'changes' on Visual Studio Code? There are over thousands of files and I was not aware of these changes since I installed vs code on my MacBook. I tried git reset --hard on the terminal, but nothing has happened. I also do not recall having these files on my laptop and VS Code cannot even open these files. VS Code also failed to notify me of these 'changes'. Whenever I try to delete all the files, it says git: fatal: you are on a branch yet to be born
See screenshot below:
All of these "changes" are most likely do to you initializing git in a folder with lots of settings and configuration folders. For example, in the screenshot, I can see that most of the "changes" are from .eclipse folder, a folder Eclipse uses to store configurations. You usually cannot see these folders, because they are "hidden" folders.
Solution 1
The first solution is to add a .gitignore file, to ignore all of those unnecessary folders. To do this, just add a file named .gitignore to the current folder. Then in that file, put a list of all of the folders to be ignored. For example(Go through the list of "changes" and add more folders):
/.eclipse
Solution 2
The other solution to seeing these changes is just deleting the .git folder. You can't see this folder by default, because it is a hidden folder. To see this, you have to go to Finder, and press Command + Shift + .. After you see the .git folder, you can just delete it. The changes should now go away.
I come from SourceTree to board the GitKraken hype train. It has always been pretty easy to ignore files within ST. Just right-click on a file in the unstaged container and you've all the options. You can ignore the files directly, each file beneath a specific folder etc. (so, all the .gitignore stuff from within the GUI =)).
However, I can't find a similar feature in GitKraken. Does anybody know how I can ignore files via the GUI of GitKraken?
Please note: This is not a git question. I absolutely know in depth how ignoring files in Git work. But that's not the topic whatsoever. This is just a trivial GitKraken support question.
Currently there isn't an option to ignore a file through the GitKraken GUI.
If you check their post on twitter this is planned to be implemented soon and it will be in their release notes once this is completed.
UPDATE (26.01.2017.):
Version 2.0.0 brings the .gitignore option to the list of functionalities. You can now select a file or folder in the file staging area, and add to the .gitignore file on the fly. Right-click and select Ignore. From there, you can:
Add that specific file to .gitignore
Add all files with that file extension to .gitignore
Add all files in the same folder as the selected file to
.gitignore
(If selecting a folder) add that folder to the .gitignore
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 used computer A via the Terminal to create a) create a git repository, b) add an index.html file to the repo, c) add a remote origin, d) push to the remote origin. All OK.
Then, i used computer B to clone that repository via Terminal. Then, I opened Eclipse (equipped with Egit), and created a new project in the folder that was created by the cloning process. Then I used Eclipse to push any changes to the remote origin.
Returning to computer A, I used Eclipse to create a project in the original repo folder, and then I attempted to pull from the remote origin, in order to get the changes that were pushed when using computer B.
Eclipse will not do it. It complains the I have items such as .settings, .project and similar and since they are not under version control it won't overwrite them by fetching files from the server. I had to manually delete those files (via Terminal) and then Eclipse worked as expected.
Please provide information on how to avoid this.
Should I create the local repo from within Eclipse and then push it to the remote origin, so that items such as (.settings) are under version control and (if so) how would that cause trouble to people cloning the repo and use different versions of Eclipse?
Should I gitignore those items?
Should I ask Eclipse to save its own affiliated files to another folder (not that i am aware how to do that, i only know that NetBeans does it)?
Looks like you didn't gitignored eclipse files.
Probably, when you commit/push via egit, you also commit and push those files you already had unversioned in your machine A, so git complains, because you are asking to override existing unversioned files.
I strongly recommend you to gitignore those eclipse files. You can see examples of .gitignore files in the github gitignore repo.
Hope it helps.
It complains because if you pull the changes from your remote it will overwrite your local files. That is the problem. The other answerer has right. You should better add all the eclipse project files and and target .settings and classpath to gitignore. You can use a global gitignore for your computers as well, before creating projects. You could use maven for example, then you can import your projects only from the pom.xml-s given in the git repository.
I use them the same. Egit and other guis are a bit too complex to work with. Git repositories can get easy in an inconsistent state where you should use the oldfashioned terminal to solve things. Like, rebasing, merging on conflicts. Gits learning curve is solid.
Now you can solve your problem if on the first computer save a backup of your original and clones your project later, after fixed it on the second. On the second git remove all this files, but use the --cached option to avoid deleting them. Before you do it so, check the help of git remove! after you have done this, put them into the .gitignore as filenames with wildcards. You can also use a global gitignore file in your user folder. Creating a .gitconfig file where you can specifiy the global ignore with the following :
[core]
excludesfile = ~/.gitignore_global
Than just create the .gitignore_global like this :
/nbproject
/bin
/build.xml
.idea
chess.iml
target/
bin
( This file is for idea and netbeans. you can add eclipse project files here )
You can have .gitignore files per project too. You can commit them to the repository, so on the next machine you do not have to do this again. The nicest way I think is having a dotfiles git repository, which is a git repo of your home directory and the dotfiles in it. I also use it for different windows and linux distros.
That's all. You should keep all of your configuration in a safe place. And source code management can do it. But do not commit private stuff to public a place! ;)
Oh I wanted to mention that, you can also have a .gitignore entry in your .gitignore file. That can be very useful when you do not want to touch a repository but need to add a gitignore to hide some stuff especially from the given repo.
I'm wondering where to put .hgignore file; in the main repository or each programmer should have it on his cloned copy?
Please clarify. Thanks.
You should put the file at the root of your repository.
See :
https://www.selenic.com/mercurial/hgignore.5.html
https://www.mercurial-scm.org/wiki/.hgignore
It says:
These files can be ignored by listing them in a .hgignore file in the root of the working directory. The .hgignore file must be created manually. It is typically put under version control, so that the settings will propagate to other repositories with push and pull.
Also another advantage is that, you might be working on multiple projects. Each having it's own set of pattern of files to ignore. For example, working on a Visual Studio project or a simple C++ project or a Python project. This ensures that patterns to ignore are relevant to the project.
How ever, you may not want to replicate these patterns in every ignore files. In such a case Mercurial configuration file can reference a set of per-user or global ignore files.
Example for global ignore files
in ~/.hgrc1:
[ui]
ignore = ~/.hgignore
in ~/.hgignore:
syntax: glob
*.tex
*.R
1 On Windows: %USERPROFILE%\mercurial.ini, ~ refers to %USERPROFILE% on Windows.
I've never seen it anywhere but the main repository.
How are you going to ignore the .hgignore without an .hgignore file in the repositry to ignore it ;P
Seriously.. it should probably be in the repository, since the files to be ignored are respositry-specific; a user can of course specify their own ignores additionally in a file specified in their .hgrc
you can have a global one inside your ~/.hgrc directory or a project specific one inside
the project's root directory
It belongs in the top folder of the repository. It is not meant for personal ignores but for project-wide ignores (i.e. applying for everyone). However, usually developers will add e.g. their faviourite editor's temp. files to that file - doesn't hurt anyone.
If you want to ignore something others probably do NOT want to ignore, put it in your personal ignore in ~/.hgrc.