What is git’s “filemode”?

A git bare repo (detailed here) has no relation with filemode.

A bare repository is used as a target, to push to.
You can push to a bare repository, because since it has no working tree: there is no concern about maintaining said working tree in sync with what you just pushed.

what is a “fake” file? and what constitutes a “working” directory?

There is no “fake” file. It is just that a bare repo only contains git’s administrative and control files, not actual data file you could work with and modify.
Those are checked out in a “working directory”, when the repo is not bare.

The git config man page

core.fileMode

If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT (File Allocation Table).
See git-update-index.

The command honors core.filemode configuration variable.
If your repository is on a filesystem whose executable bits are unreliable, this should be set to false.
This causes the command to ignore differences in file modes recorded in the index and the file mode on the filesystem if they differ only on executable bit.
On such an unfortunate filesystem, you may need to use git update-index --chmod=.

For me, it’s in every repo’s ./git/config file, near the top,

Me too, but on Windows, it is always:

git config --local core.filemode
false

Don’t forget that git only records two filemodes:

• 644
• 755

---

With Git 2.37.3 (Q3 2022), “git fsck“^(man) is better at detecting invalid file modes.

Before 2.37.3, It was reading mode from tree objects but canonicalizes the mode before passing it to the logic to check object sanity, which has hid broken tree objects from the checking logic.
This has been corrected, but to help exiting projects with broken tree objects that they cannot fix retroactively, the severity of anomalies this code detects has been demoted to “info” for now.

See commit 4dd3b04, commit 53602a9, commit ec18b10 (10 Aug 2022) by Jeff King (peff).
^{(Merged by Junio C Hamano — gitster — in commit 363a193, 18 Aug 2022)}

fsck: actually detect bad file modes in trees

^{Reported-by: Xavier Morel
Signed-off-by: Jeff King}

We use the normal tree_desc code to iterate over trees in fsck, meaning we only see the canonicalized modes it returns.
And hence we’d never see anything unexpected, since it will coerce literally any garbage into one of our normal and accepted modes.

We can use the new RAW_MODES flag to see the real modes, and then use the existing code to actually analyze them.
The existing code is written as allow-known-good, so there’s not much point in testing a variety of breakages.
The one tested here should be S_IFREG but with nonsense permissions.

Do note that the error-reporting here isn’t great.
We don’t mention the specific bad mode, but just that the tree has one or more broken modes.
But when you go to look at it with “git ls-tree“^(man), we’ll report the canonicalized mode!
This isn’t ideal, but given that this should come up rarely, and that any number of other tree corruptions might force you into looking at the binary bytes via “cat-file”, it’s not the end of the world.

The warning is:

warning in tree $tree: badFilemode: contains bad file modes