45

What is git filemode? For me, it's in every repo's ./git/config file, near the top:

 [core]
    filemode = true

What is it? What does it mean? Does it bear any relation to

    bare = false

which I also don't really understand?

mikemaccana
  • 110,530
  • 99
  • 389
  • 494
Alex Gray
  • 16,007
  • 9
  • 96
  • 118

2 Answers2

57

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
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 11
    And (as a side note) `core.filemode` and `core.fileMode` are the same variable, as these git config entries are case-insensitive. (I don't know why the documentation is inconsistent in using all lowercase sometimes, and camelCase other times.) – torek Oct 27 '13 at 22:14
  • Can you clarify your second sentence? It contains the word "it" three times and we don't know what they all refer to. TIA – MartinThurn Jan 10 '22 at 16:04
  • @MartinThurn Good point. I have rewritten the introduction, let me know if this is clearer. – VonC Jan 10 '22 at 18:31
  • "git only records two filemodes" .. so when you `git pull` or `git checkout`, the file permissions are set to 644 or 755, and those are then altered by your umask to give you the final file permissions? (Assuming no hooks that then further alter the file permissions). – Kevin Wheeler Sep 02 '22 at 03:37
  • @KevinWheeler Exactly, as [noted here](https://stackoverflow.com/a/68195950/6309), and [here](https://stackoverflow.com/a/40979867/6309): `umask` is always applied. – VonC Sep 02 '22 at 13:46
21

filemode set true means file mode executable-bit permission changes are considered changes to be committed.

bare set true means the directory is not a working directory (no real files, only the git repository itself).

Lutz Prechelt
  • 36,608
  • 11
  • 63
  • 88
cforbish
  • 8,567
  • 3
  • 28
  • 32
  • what is a "fake" file? and what constitutes a "working" directory? – Alex Gray Oct 27 '13 at 20:19
  • I do not understand the fake file question. A working directory is one where you can actually commit changes. A bare directory is one that is normally found on the remote server. You can also create a bare directory with git init --bare. – cforbish Oct 28 '13 at 02:28
  • 12
    [filemode](https://www.kernel.org/pub/software/scm/git/docs/git-config.html) only refers to the executable bit, not all permissions (e.g. `chmod -w file` is a no-change for git). – AD7six Oct 28 '13 at 09:14