There are a number of files that we track in the repo, but are nevertheless covered by `.gitignore`.

This *mostly* doesn't change anything, because Git itself only cares what `.gitignore` has to say about files that aren't already tracked.  But:

* It affects any new files someone might add that are covered by the same unintentionally-broad patterns.  In that case it'd be likely to cause some confused debugging into why Git wasn't seeing the file; or possibly loss of work, if the person didn't notice that the file had never been committed to Git.

* More immediately, other tools that aren't Git but consult the Git ignore rules don't necessarily implement this wrinkle. In particular this is unfortunately a WONTFIX bug in ripgrep / `rg`: https://github.com/BurntSushi/ripgrep/issues/1127 .

I learned of the `rg` bug (and, for that matter, refreshed myself on just how Git itself handles this case) after some confusion today where I was looking with for references to a given macro, thought I'd looked at all of them... and then later noticed through `git log -p -S` a reference in `PC/pyconfig.h` with no subsequent change deleting it. Turned out it was indeed there and I needed to take account of it.

Here's the list of affected files:

$ git ls-files -i --exclude-standard 
.gitignore
Doc/Makefile
Lib/test/data/README
Modules/Setup
PC/pyconfig.h
Tools/freeze/test/Makefile
Tools/msi/core/core.wixproj
Tools/msi/core/core.wxs
Tools/msi/core/core_d.wixproj
Tools/msi/core/core_d.wxs
Tools/msi/core/core_en-US.wxl
Tools/msi/core/core_files.wxs
Tools/msi/core/core_pdb.wixproj
Tools/msi/core/core_pdb.wxs
Tools/unicode/Makefile

Fortunately this is not hard to fix.  The semantics of `.gitignore` have a couple of gotchas, but once you know them it's not really any more complicated to get the behavior exactly right.  And I've previously spent the hour or two to read up on it... and when I forget, I just consult my own short notes :), at the top of this file:
https://github.com/zulip/zulip/blob/master/.gitignore

I have a minimal fix which takes care of all the files above. I'll post that shortly, and I may also write up a more thorough fix that tries to make it easy not to fall into the same Git pitfall again.