Git – ignoring any ‘bin’ directory on a git project

gitgitignore

I have a directory structure like this:

.git/
.gitignore
main/
  ...
tools/
  ...
...

Inside main and tools, and any other directory, at any level, there can be a 'bin' directory, which I want to ignore (and I want to ignore everything under it too). I've tried each of these patterns in .gitignore but none of them work:

/**/bin/**/*
/./**/bin/**/*
./**/bin/**/*
**/bin/**/*
*/bin/**/*
bin/**/*
/**/bin/* #and the others with just * at the end too

Can anyone help me out? The first pattern (the one I think should be working) works just fine if I do this:

/main/**/bin/**/*

But I don't want to have an entry for every top-level directory and I don't want to have to modify .gitignore every time I add a new one.

This is on Windows using the latest msysgit.

EDIT: one more thing, there are files and directories that have the substring 'bin' in their names, I don't want those to be ignored 🙂

Best Answer

Before version 1.8.2, ** didn't have any special meaning in the .gitignore. As of 1.8.2 git supports ** to mean zero or more sub-directories (see release notes).

The way to ignore all directories called bin anywhere below the current level in a directory tree is with a .gitignore file with the pattern:

bin/

In the man page, there an example of ignoring a directory called foo using an analogous pattern.

Edit: If you already have any bin folders in your git index which you no longer wish to track then you need to remove them explicitly. Git won't stop tracking paths that are already being tracked just because they now match a new .gitignore pattern. Execute a folder remove (rm) from index only (--cached) recursivelly (-r). Command line example for root bin folder:

git rm -r --cached bin

Related Solutions

Git – the difference between ‘git pull’ and ‘git fetch’

In the simplest terms, git pull does a git fetch followed by a git merge.

You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy. I have even heard of people running git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).

A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.

From the Git documentation for git pull:

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

Git – How to undo ‘git add’ before commit

You can undo git add before commit with

git reset <file>

which will remove it from the current index (the "about to be committed" list) without changing anything else.

You can use

git reset

without any file name to unstage all due changes. This can come in handy when there are too many files to be listed one by one in a reasonable amount of time.

In old versions of Git, the above commands are equivalent to git reset HEAD <file> and git reset HEAD respectively, and will fail if HEAD is undefined (because you haven't yet made any commits in your repository) or ambiguous (because you created a branch called HEAD, which is a stupid thing that you shouldn't do). This was changed in Git 1.8.2, though, so in modern versions of Git you can use the commands above even prior to making your first commit:

"git reset" (without options or parameters) used to error out when you do not have any commits in your history, but it now gives you an empty index (to match non-existent commit you are not even on).

Documentation: git reset

Best Answer

Related Solutions

Git – the difference between ‘git pull’ and ‘git fetch’

Git – How to undo ‘git add’ before commit

Related Topic