How can I stop .gitignore from appearing in the list of untracked files?

Question

I just did a git init on the root of my new project.

Then I created a .gitignore file.

Now, when I type git status, .gitignore file appears in the list of untracked files. Why is that?

Acclimatize

git add self && git commit -m "-1 for reverting existential depression" && git remote rm HEAD – Legumin

Can I ignore the .git/ folder and put it in ".gitignore"? – Ferne

You could create a global "gitignore" in your home folder under Linux and store it there: git config --global core.excludesfile ~/.gitignore_global – Ferne

I came here by searching how to gitignore .gitinore file and the question and accepted answer aren't really related to title. Title could be improve. – Azole

@matheusrufca: looks like the answer is that you shouldn't ignore the .gitignore file. Why do you want it? – Shonda

There are use cases for ignoring .gitignore. My team's workflow requires me to change a set of files for my local dev environment but they should not be committed. The workflow could be improved with better architecture but it's out of my hands. In the meantime, having git pay attention to those files is a liability. Thus I want to gitignore them but only locally, and I don't want to risk committing my .gitignore as it should not be shared with the team. – Gelsenkirchen

Add .gitignore in the .gitignore file – Guenther

Add .gitignore in the .gitignore file @Guenther - doesn't work. – Cypriot

you can use git rm --cached .gitignore and untracking .gitignore – Exclamatory

Answer 1

The .gitignore file should be in your repository, so it should indeed be added and committed in, as git status suggests. It has to be a part of the repository tree, so that changes to it can be merged and so on.

So, add it to your repository, it should not be gitignored.

If you really want you can add .gitignore to the .gitignore file if you don't want it to be committed. However, in that case it's probably better to add the ignores to .git/info/exclude, a special checkout-local file that works just like .gitignore but does not show up in "git status" since it's in the .git folder.

See also https://help.github.com/articles/ignoring-files

Resendez

Shouldn't this be part of the repository's metadata rather than a file that is tracked? – Imidazole

The repository metadata is local to the repository. If you add a commit hook to your repo, and someone clone your repo, they won't get the commit hook, for example. – Resendez

@wukong, if you're working on a team, shouldn't everyone should be ignoring the same set of files? That's why the .gitignore file gets added to the repository. No one says you have to deploy it as part of your project. – Channing

@Imidazole and wukong It doesn't have to be a file in your repo. You can have your ignore settings in many different places. GitHub has a great article on it help.github.com/ignore-files You can have global ignore settings anywhere, and you can have repo specific settings in the .git metadata for the repo. – Potamic

@Potamic Isn't it dangerous practice to do this, if half a team end up ignoring files that another half is actually working on (and the project comes to depend on)? – Promenade

A global ignore file is very nice for files that are local to that particular environment. For example, a .DS_Store file is specific to Finder.app on OS X and does not really belong in the .gitignore file of the project. Same goes with eclipse and intellij files, unless of course there's a rule that everyone working on the project use a particular IDE. – Resendez

@Promenade In using these ignore files you certainly need to use judgement in what you put into them, but they still have some great uses. For example I use Vim and so in my global gitignore I have *.swp files marked as ignored. This way I don't have to add it to each of my projects, and guys who don't ever use vim don't have to worry about it. – Potamic

@Kyralessa well I'm using git-svn while the rest of the team is using svn, so its useful for me to actually ignore .gitignore, probably there are other use cases as well – Lawman

For git-svn, I don't have a gitignore file. I use .git/info/excludes, which is a repository local file that won't show up in "git status", but it works just like gitignore. – Resendez

So if you use .git/info/exclude instead of .gitignore, then others who clone your repo won't ignore those same files? – Ambrosio

Exactly. It's useful for files that you want to have floating about but don't have a better folder for than the git repo :) I some times have an "etc" folder that I ignore in .git/info/excludes, where I put various documents, downloads, etc I don't want to check in. For git-svn it also works well, unless you want to check a .gitignore file into an svn repo :) – Resendez

@Imidazole and others, if you want ignored files to apply to only your repo, and not those of your collaborators, use .git/info/exclude. – Kamal

it is worth mentioning that adding '.gitignore' to the .gitignore file does not actually cause it to be ignored, and it still shows up in git status – Hukill

I work in a team, and while we do want to ignore the same set of core patterns, I have been asked to use a global .gitignore for e.g. the pattern *.swp. This is created by Vim, which only some of my team (including me) use for writing code. – Synchronic

I find useful to have convention what to ignore, create initial .gitignore file, and than "seal" it by adding .gitignore to itself. That way you are safe from the accidents, but you can change it if you really want, by "unsealing", updating and "sealing" it again. Everybody can manage it locally if needed, but without committing changes. – Greenberg

My team and I have found that it's best to put project related things in the .gitignore file and dev/env/machine related files in the .git/info/exclude file. This way we don't bloat up the gitignore list with things that may be relevant to only one person because he/she has chosen a specific dev setup. Concrete example: the .DS_Store files are only relevant to me because I'm using macOS – Twine

adding '.gitignore' to the .gitignore file is just the short answer that is needed. – Sporting

To summarize, .gitignore is used to ignore files for all users, while .git/info/exclude is used to ignore files only for the current user – Individualist

Answer 2

If you want to store the list of ignored files outside of your Git tree, you can use the .git/info/exclude file. It is applied only to your checkout of the repo.

Espionage

+1, this is great for ignores that aren't project related, such as emacs *~ backup files, .DS_Store from OS X and so on. – Resendez

@AugustLilleaas I personally prefer to put these types of {editor,platform}-specific files in ~/.gitignore so they're ignored for any repository I work on. – Azedarach

Once a file is tracked, you can use git update-index --assume-unchanged <file> to stop tracking changes without changing your repo. This is very useful on large shared projects where you need to make local changes, but nobody else wants to see your stuff committed to the repo. See blog.pagebakers.nl – Teeth

@AugustLilleaas: Per-user gitignore is better for that use-case. – Huber

thanks for this tip, i'm using git-svn so the other users of the svn repo on the server wouldn't exactly want .gitignore checked in. – Opposable

This is particularly helpful when you are using git svn because other contributors on your team may not want to see anything related to git in the subversion repository. – Decennium

The .git directory is in the base of your repository, not necessarily the working directory. – Stedmann

Answer 3

You could actually put a line .gitignore into your .gitignore file. This would cause the .gitignore file to be ignored by git. I do not actually think this is a good idea. I think the ignore file should be version controlled and tracked. I'm just putting this out there for completeness.

Cathryncathy

Worked for me! version 1.5.6.5. I also agree with 1800 INFORMATION that its not a good idea, but I think it could be okay in certain contexts (say you use a git-svn repository, and you don't want git-ish files to go to svn). The excludes file is probably better. – Sin

@ehsanul - the file must not be tracked (you should not have added or commited it). You can untrack it. This is probably not a great idea in a git-only environment, but if you happen e.g. to use git as a smart client for a subversion repository (without the rest knowing, <maniacal laughter>) - such a trick is great. – Toilet

@IshanSrivastava You probably have the file tracked already. Try running git rm --cached .gitignore – Derte

This solution works for me as I just need to ignore changes in my repo. The actual commit is inside subfolders (projects). – Forgave

Answer 4

You can also have a global user git .gitignore file that will apply automatically to all your repos. This is useful for IDE and editor files (e.g. swp and *~ files for Vim). Change directory locations to suit your OS.

1. Add to your ~/.gitconfig file:

   [core]
   excludesfile = /home/username/.gitignore
   

2. Create a ~/.gitignore file with file patterns to be ignored.

3. Save your dot files in another repo so you have a backup (optional).

Any time you copy, init or clone a repo, your global gitignore file will be used as well.

Stafani

I believe this is the best solution for situations where your editors leave behind temp files, e.g. .*.swp (VIM) and ._* (TM), since it wouldn't make sense to continuously add these rules to every git repo, and to force other users with different IDE's to check for these files. – Brawn

This works brilliantly for ignores that shouldn't be pushed to any branch. Replace 'username' with your actual username of course, and don't add a second [core] section to .gitconfig if you already have one - just place the excludesfile line under your existing [core] section. – Stedmann

Answer 5

If someone has already added a .gitignore to your repo, but you want to make some changes to it and have those changes ignored do the following:

git update-index --assume-unchanged .gitignore

Source.

Oxford

Bad idea, there is a reason .git/info/excludes exists. – Diaper

I presume there's a reason --assume-unchanged exists too. Why is one better than the other? – Oxford

And btw .git/info/excludes does not work if the file is already tracked. – Oxford

This really helped me with a .gitignore that was already committed and for which I did not wish to commit changes. I'm running git 1.7.4.1 from Ubuntu 11.04 repos and the help pages add this in update-index. "This option can be also used as a coarse file-level mechanism to ignore uncommitted changes in tracked files (akin to what .gitignore does for untracked files). Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually." – Wrapper

I vote for this answer 'cause generally you'll need this action for your master repo initial state and keep the benefits of git functionality. There is no good reason to ignore this file (period) – Amplify

Just for completeness purposes, how can you revert this action? --no-assume-unchanged is the right way – Saenz

This is helpful if the file is already tracked and exists on remote. From what I have found so far, this is the only command that, when used together with .git/info/excludes, ignores any file and at the same time does not require an extra commit. – Schram

Answer 6

After you add the .gitignore file and commit it, it will no longer show up in the "untracked files" list.

git add .gitignore
git commit -m "add .gitignore file"
git status

Element

Answer 7

First of all, as many others already said, your .gitignore should be tracked by Git (and should therefore not be ignored). Let me explain why.

(TL;DR: commit the .gitignore file, and use a global .gitignore to ignore files that are created by your IDE or operating system)

Git is, as you probably already know, a distributed version control system. This means that it allows you to switch back and forth between different versions (even if development has diverged into different branches) and it also allows multiple developers to work on the same project.

Although tracking your .gitignore also has benefits when you switch between snapshots, the most important reason for committing it is that you'll want to share the file with other developers who are working on the same project. By committing the file into Git, other contributers will automatically get the .gitignore file when they clone the repository, so they won't have to worry about accidentally committing a file that shouldn't be committed (such as log files, cache directories, database credentials, etc.). And if at some point the project's .gitignore is updated, they can simply pull in those changes instead of having to edit the file manually.

Of course, there will be some files and folders that you'll want to ignore, but that are specific for you, and don't apply to other developers. However, those should not be in the project's .gitignore. There are two other places where you can ignore files and folders:

• Files and folders that are created by your operating system or IDE should be placed in a global .gitignore. The benefit is that this .gitignore is applied to all repositories on your computer, so you don't have to repeat this for every repository. And it's not shared with other developers, since they might be using a different operating system and/or IDE.
• Files that don't belong in the project's .gitignore, nor in the global .gitignore, can be ignored using explicit repository excludes in your_project_directory/.git/info/exclude. This file will not be shared with other developers, and is specific for that single repository

Afrit

Nice mentioning for global .gitignore – Archbishopric

I think that after initial setup the .gitignore file should be ignored, so there are no accidental changes. It doesn't mean it cannot be changed anymore, but it is protected from accidents, in a way. Accidents on that file can introduce confusion or even endanger some work, so "sealing" (ignoring itself) should be considered also. – Greenberg

@Sasa .gitignore only works for ignoring files that are not being tracked by Git yet. Adding an already tracked file to .gitignore will not prevent you from commiting changes to that file. Even if this were possible, how would you commit the changed .gitignore when it instructs Git to ignore itself? – Afrit

@Nic - I have passed the detailed explanation to my point of view in the separate reply @ the bottom of this thread. – Greenberg

Answer 8

Just incase someone else has the same pain we had. We wanted to exclude a file that had already been committed.

This post was way more useful: working with .git/info/exclude too late

Specifically what you need to ignore a file is actually use the command git remove See git rm (http://www.kernel.org/pub/software/scm/git/docs/git-rm.html)

you test it by going

git rm --dry-run *.log
(if you say wanted to exclude all the log files)

this will output what would be excluded if you ran it.

then

you run it by going

git rm *.log
(or whatever filename path / expression you want to)

Then add a *.log line to your .gitignore file.

Ripon

Of course, you might want to follow this up with adding the relevant patterns (i.e., *.log) to your .gitignore, so they don't clutter your git status if they show up in the future. – Fanion

Although my problem wasn't related to the same as the OP's: Thanks for letting me know that I would need to use RM to "clean" up my repo after I make changes to .gitignore (if files are already comited.) Noob error, I know, but this was the first place that I personally have seen anyone mention that. – Townie

Thanks for the feedback. Yeah that's why I wrote it, having come here and then going the long way around to work this out also, thought it would be good to write it up. :) – Ripon

Answer 9

Of course the .gitignore file is showing up on the status, because it's untracked, and git sees it as a tasty new file to eat!

Since .gitignore is an untracked file however, it is a candidate to be ignored by git when you put it in .gitignore!

So, the answer is simple: just add the line:

.gitignore # Ignore the hand that feeds!

to your .gitignore file!

And, contrary to August's response, I should say that it's not that the .gitignore file should be in your repository. It just happens that it can be, which is often convenient. And it's probably true that this is the reason .gitignore was created as an alternative to .git/info/exclude, which doesn't have the option to be tracked by the repository. At any rate, how you use your .gitignore file is totally up to you.

For reference, check out the gitignore(5) manpage on kernel.org.

Stumpf

just the short answer needed for a simple question. – Sporting

Answer 10

The idea is to put files that are specific to your project into the .gitignore file and (as already mentioned) add it to the repository. For example .pyc and .o files, logs that the testsuite creates, some fixtures etc.

For files that your own setup creates but which will not necessarily appear for every user (like .swp files if you use vim, hidden ecplise directories and the like), you should use .git/info/exclude (as already mentioned).

Tremolo

Answer 11

Watch out for the following "problem" Sometimes you want to add directories but no files within those directories. The simple solution is to create a .gitignore with the following content:

*

This seams to work fine until you realize that the directory was not added (as expected to your repository. The reason for that is that the .gitignore will also be ignored, and thereby the directory is empty. Thus, you should do something like this:

*
!.gitignore

Anteroom

Answer 12

This seems to only work for your current directory to get Git to ignore all files from the repository.

update this file

.git/info/exclude 

with your wild card or filename

*pyc
*swp
*~

Turnspit

Answer 13

If you've already checked in .gitignore and you want to ignore modifications to it, check out this answer:

Try using this command:

git update-index --assume-unchanged FILENAME_TO_IGNORE

To reverse it (if you ever want to commit changes to it), use:

git update-index --no-assume-unchanged

UPDATE:

Here's how to list 'assume unchanged' files under current directory:

git ls-files -v | grep -E "^[a-z]"

As the -v option will use lowercase letters for 'assume unchanged' files.

Protero

Answer 14

In my case, I want to exclude an existing file. Only modifying .gitignore not work. I followed these steps:

git rm --cached dirToFile/file.php
vim .gitignore
git commit -a

In this way, I cleaned from cache the file that I wanted to exclude and after I added it to .gitignore.

Garvin

best solution for me. you can also use git add . in the second place , after that git commit -m "fixing .gitignore" – Aesthesia

Answer 15

Navigate to the base directory of your git repo and execute the following command:

echo '\\.*' >> .gitignore

All dot files will be ignored, including that pesky .DS_Store if you're on a mac.

Kulp

I wouldn't do that. There might be dot files you need. Instead, I would just add .gitignore and .DS_Store literally. – Tribunate

Answer 16

It is quite possible that an end user wants to have Git ignore the ".gitignore" file simply because the IDE specific folders created by Eclipse are probably not the same as NetBeans or another IDE. So to keep the source code IDE antagonistic it makes life easy to have a custom git ignore that isn't shared with the entire team as individual developers might be using different IDE's.

Colmar

Answer 17

I found that the best place to set up an ignore to the pesky .DS_Store files is in the .git/info/exclude file.

IntelliJ seems to do this automatically when you set up a git repository in it.

Bladdernut

The user's global ignore file would be a better place to ignore .DS_Store – Bordereau

Answer 18

.gitignore is about ignoring other files. git is about files so this is about ignoring files. However as git works off files this file needs to be there as the mechanism to list the other file names.

If it were called .the_list_of_ignored_files it might be a little more obvious.

An analogy is a list of to-do items that you do NOT want to do. Unless you list them somewhere is some sort of 'to-do' list you won't know about them.

Danseur

Answer 19

I think that there are situations where ignoring the .gitignore is very useful. For instance, when you have multiple teams or a large team working on the same codebase. In that case, you need to have certain conventions, one of those convention is regarding what is ignored at the git repo. It is usually about ignoring files and directories created by IDE or OS, some generated logs, etc.

However, there is a force which is tending to introduce non-conventional changes to .gitignore file. The .gitignore file can be further changed by irresponsible person, by mistake, by a tool that is used, or in some other case.

To have a counter force to this, we can do as followed:

1. The initial .gitignore should reflect convention in team(s),
2. After it is pushed, the .gitignore should be secured by adding .gitignore entry and push that change again.The .gitignore file is "sealed" in this way.

The "sealed" .gitignore file can be changed, just locally, without propagating that changers to other members of team(s). However, if a change is widely agreed throughout the whole team(s) than it is possible to "unseal" it, change it and than "seal" it again. That can't be done by mistake, only intentionally.

Sadly, you cannot be 100% protected from the stupidity, but this way you have done everything you can to prevent stupid things to happen.

If you have relatively small team with very good professionals, than this wouldn't be important, but even those guys would appreciate to have one thing less to worry about.

Using .git/info/exclude is cool when you cannot do anything about infrastructure settings, just covering your own a** not to make a mistake.

From a standing point of what is right and what is wrong I am voting for having .gitignore entry inside .gitignore file, giving everybody the freedom to do locally whatever they want, but not invading others.

Maomaoism