On 25 September 2012 16:13, Junio C Hamano <gits...@pobox.com> wrote:
> Hilco Wijbenga <hilco.wijbe...@gmail.com> 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

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to