On 25 September 2012 16:13, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> writes: > >> Naturally, this behaviour makes perfect sense: "/*" means everything. >> Still, I was wondering whether it might be a good idea to make an >> exception for '.gitignore' itself? Then if somebody *really* wanted to >> ignore '.gitignore' they could add "/.gitignore" to '.gitignore'? > > If somebody is sick enough to ignore "everything", he can add "/*" > to the .gitignore file and in order to make sure he knows what he is > doing and he is doing what he thinks is doing, he would check with > "git diff --stat HEAD" etc. before committing, and double check with > "git show --stat" etc. after committing. Ignoring everything is not quite so "sick". :-) My use case is Eclipse's .metadata directory. This directory is *huge* but only .metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs is really of interest (and not even all of those files). The subset of *.prefs that we are interested in will allow us to share Eclipse configuration settings (things like formatting settings and which warnings we care about). So I have several '.gitignore' files with "/*" + "!/some-dir/". [To make things even more interesting, the ".settings" directory should be ignored in all other places (so it's in our top level '.gitignore').] I would be very happy to find out better ways to handle this particular scenario. I had quite a struggle getting it to work. > ".gitignore" (or ".gitattributes" for that matter) shouldn't be any > different from your ordinary tracked contents. If you have "*.o" in > the ignored pattern list, you would need an extra care to defeat the > pattern to add vendor-supplied binary-only object file with "add -f" > and live with the fact that a new vendor-supplied binary-only object > file not appearing on untracked list. It is exactly the same deal. I do not entirely agree. I think '.gitignore' *is* different. This file is special and affects Git's behaviour. And it does so *before* it has been committed. Or even added. The fact that '.gitignore' itself is not listed in the output of, e.g., "git status" is easy to miss. I have not really used '.gitattributes' but I assume the same applies. > Having said that, I guess you could add "!.git*" to your > $GIT_DIR/info/exclude and see if it gives an improved user > experience. Mmm, that does not seem to help. I did git init && touch file.txt && echo '/*'>.gitignore && echo '!.gitignore' >>.git/info/exclude && git status it lists nothing (Git 1.7.12). I had expected to see '.gitignore'. Did I misunderstand you? Even so, this would only improve *my* user experience, wouldn't it? This would not get pushed to the central repository so it would not help anyone else. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html