tags:

views:

3001

answers:

5

Hi, 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 :)

+9  A: 

The .gitignore of your dream seems to be:

bin/

on the top level.

Michael Krelin - hacker
You're a genius :) That worked, but I don't want to ignore files and directories that have 'bin' as part of their names, sorry. I've added that to the question description, but you still get a vote up :)
Ben Hymers
But it will not get files that have `bin` as a part of their names ignored. I didn't say `*bin*`, did I?
Michael Krelin - hacker
The only drawback is that it will ignore `bin` *files*, not only directories. I can't tell right out of my head whether using `bin/` will cure that, but it may.
Michael Krelin - hacker
Yep, bin/ works, you get an extra vote up for your comment ;)
Ben Hymers
Wish I knew what could be the possible reason for downvote here. It's not that I mind, but I'm surely curious.
Michael Krelin - hacker
Heh, thanks Bombe, now the '/' is in the answer ;-)
Michael Krelin - hacker
A: 

bin/* seems to work for me but I might not have got all cases

Mark
bin/* doesn't seem to work for me. bin/ actually works better!
Ben Hymers
A: 

Oh gawd, I hate to answer my own question whilst it's still so fresh, but it seems I've stumbled upon the answer anyway.

/*/**/bin/**/*

Nice and symmetrical. This looks like the only way to avoid other files and directories with 'bin' as part of their names also getting ignored.

Anybody have any idea why it didn't work without that first *? Does ** not do what it normally does (match any number of directories) if it's the first thing in the expression?

Ben Hymers
I'm over-thinking a simple problem... bin/ works just fine!
Ben Hymers
+24  A: 

I've no idea where the impression that ** has any special meaning in a .gitignore pattern comes from. It's not mentioned in the gitignore man page or the fnmatch man page which the gitignore man page refers to.

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/

This should be pretty clear from the gitignore man page. There's even an example of ignoring a directory called foo using an analogous pattern.

Charles Bailey
Yep, I read the man page, I just assumed the foo/ example meant relative to the .gitignore file (or root if not in a .gitignore), I didn't realise it could be anywhere. bin/ is exactly right, hacker suggested it in a comment and I discovered it when replying to Mark, but yours is an answer so I shall accept it. And I won't accept my own since it's a bit over-the-top ;)
Ben Hymers
Oh, also I've read about ** all over the place. There's even a post on SO explaining it here:http://stackoverflow.com/questions/681262/difference-in-the-paths-in-gitignore-fileBut as I say, it seems to be not quite doing that here, when used at the beginning of a pattern.
Ben Hymers
I don't believe that any answer on your linked question has fully answered the issue. `fnmatch` is a standard POSIX function so it is reasonable for git to use the defined behaviour of `fnmatch` in its ignore implementation. It does mean that git is open to portability issues on platforms that supply a non-standard `fnmatch` implementation, though.
Charles Bailey
+1  A: 

I didn't see it mentioned here, but this appears to be case sensitive. Once I changed to /Bin the files were ignored as expected.

Cory
This isn't an answer to the original question which was explicitly about `bin`, not `Bin`.
Charles Bailey
Though not an answer, it does add to the completeness for others searching on the same issue (myself, just now).
Jay