confused about preserved permissions

Hello,

I am a bit confused about how git stores and restores permissions. I went to the web but found little other than this post from Linus in 2005:

  http://www.gelato.unsw.edu.au/archives/git/0504/0870.html

where he basically says that git will *not* save permissions and that it also does not save symlinks. I thus discarded the information as being outdated. I have also looked into the source, but the following question is more about git design than implementation.

Let me illustrate the source of my confusion:

  $ git init
  Initialized empty Git repository in .git/
  $ umask
  002
  $ date > file1; ls -l file1
  -rw-rw-r-- 1 madduck madduck 30 2007-08-20 18:15 file1
  $ git add file1; git commit -m.
  Created initial commit 5762460: .
  1 files changed, 1 insertions(+), 0 deletions(-)
  create mode 100644 file1

file1 is mode 664, but gut says "create mode 100644 file1", independently of whether I use --shared when initialising, or what value I set it to. Why does it override the group write bit?

But it gets worse:

  $ git checkout -b t
  Switched to a new branch "t"
  $ git rm file1; git commit -m.
  rm 'file1'
  Created commit a813b4e: .
  1 files changed, 0 insertions(+), 1 deletions(-)
  delete mode 100644 file1
  $ umask 007
  $ git checkout master
  Switched to branch "master"
  $ ls -l file1
  -rw-rw----  1 madduck madduck    30 2007-08-20 18:15 file1

So git doesn't even restore 644 when I switch branches, nor on initial clone, or on re-checkout after removing the local copy.

Am I doing something wrong?

Why does git bother saving a mode when later it never seems to use it again?

And is there a way to tell git not to mess with the permissions in the worktree when switching branches? I am not sure what's causing it since the inode of files does not seem to change, so git apparently explicitly fchmod()'s files.

I'd be grateful for any documentation to read in addition to the code. I saw core.filemode, but that's only about the x bit, it seems.

Thanks,