Hilco Wijbenga [off-list ref] 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.
".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.
Having said that, I guess you could add "!.git*" to your
$GIT_DIR/info/exclude and see if it gives an improved user
experience.
On 25 September 2012 16:13, Junio C Hamano [off-list ref] wrote:
Hilco Wijbenga [off-list ref] writes:
quoted
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.