views:

692

answers:

2

I have a lot of projects in my .Net solution. I would like to exclude all "bin/Debug" and "bin/Release" folders (and their contents), but still include the "bin" folder itself and any dll's contained therein.

.gitignore with "bin/" ignores "Debug" and "Release" folders, but also any dll's contained in the "bin" folder.

"bin/Debug" or "bin/Release" in the .gitignore file does not exclude the directories, unless I fully qualify the ignore pattern as "Solution/Project/bin/Debug" - which I don't want to do as I will need to include this full pattern for each project in my solution, as well as add it for any new projects added.

Any suggestions?

+2  A: 

Have you tried wildcards?

Solution/*/bin/Debug
Solution/*/bin/Release
jleedev
It works, except if there is a sub-folder with another project in e.g. Solution/Module/Project so for now I've added /*/*/bin/Debug and /*/*/*/bin/Debug (for sub folders). Looks like you have to add a wildcard sub folder for each level in your directory structure.
Marcel
@Marcel: Well, git certainly isn't going to ignore any files you don't tell it to - it ignores whatever matches the wildcards, no more, no less.
Jefromi
+2  A: 

You can use .gitignore in the top level to ignore all directories in the project with the same name. For example:

Debug/
Release/

This should update immediately so it's visible when you do git status. Ensure that these directories are not already added to git, as that will override the ignores.

Andreas
The same could be done by adding the patterns to the OPs `$GIT_DIR/.git/info/exclude` file.
Tim Henigan
The difference is that the .gitignore file will follow the code, so it applies everywhere. Whereas the exclude file is local to only your repository, meaning it only applies for that specific repository. Unless other committers have a reason to want to commit these directories, I would recommend using .gitignore.
Andreas
Another problem with this is if you have a project in your solution called Debug, which will then also be ignored. I think the solution is a combination of all the answers and comments - restructure the solution to keep common or referenced dll's in a different folder, then ignoring "bin/" and/or use wildcards.
Marcel