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,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
"vista is evidentally latvian for "hen", and "perating system", that
 is, OS without the o, means "system for making eggs."  so vista is at
 least useful come breakfast time?"
                                                      -- kit la touche
 
spamtraps: madduck.bogus@madduck.net

On Mon, Aug 20, 2007 at 04:44:11PM +0000, martin f krafft wrote:

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.

  You may want to read git-config around core.sharedRepository.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

also sprach Pierre Habouzit [off-list ref] [2007.08.20.1854 +0200]:

quoted

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.

  You may want to read git-config around core.sharedRepository.

Hello Pierre, thanks for taking the time to respond.

core.sharedRepository (or init --shared for that matter) seems to
only deal with permissions of $GIT_DIR. I am worrying about the
permissions of the worktree. I also stated in the OP that I had used
--shared but none of the settings made any difference...

Cheers,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
normaliser unix c'est comme pasteuriser le camembert.
 
spamtraps: madduck.bogus@madduck.net

On Mon, Aug 20, 2007 at 06:44:11PM +0200, martin f krafft [off-list ref] wrote:

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

Same applies to git-archive, which generates files with mode 666 and
directories with 777, while it could follow the modes in the
repository... or at least, that's what the manpage claims, but facts
seem to be quite different...

mh@namakemono:~/git/git$ git-archive --format=tar HEAD | tar -tvf -
-rw-rw-r-- root/root      2365 2007-08-19 20:45 .gitignore
-rw-rw-r-- root/root      1973 2007-08-19 20:45 .mailmap
-rw-rw-r-- root/root     18787 2007-08-19 20:45 COPYING
drwxrwxr-x root/root         0 2007-08-19 20:45 Documentation/
-rw-rw-r-- root/root        63 2007-08-19 20:45 Documentation/.gitignore
-rw-rw-r-- root/root      4553 2007-08-19 20:45 Documentation/Makefile
(...)
mh@namakemono:~/git/git$ git-ls-tree HEAD
100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c    .gitignore
100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d    .mailmap
100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3    COPYING
040000 tree 865a32f4b417cbb601524ac2b78ca64ff232302c    Documentation
100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200    GIT-VERSION-GEN
(...)

mh@namakemono:~/git/git$ umask
0022

And no value is set for umask in git config...

I also never understood why there were no permissions set on directories
in trees... nor why, while the sha1 for child objects are "packed", the
modes aren't...

Mike

Mike Hommey [off-list ref] writes:

On Mon, Aug 20, 2007 at 06:44:11PM +0200, martin f krafft [off-list ref] wrote:

quoted

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

Same applies to git-archive, which generates files with mode 666 and
directories with 777, while it could follow the modes in the
repository... or at least, that's what the manpage claims, but facts
seem to be quite different...

Git had permissions at one point of time.  It makes colloboration with
other people with different umasks a nuisance.  However, not all uses
are colloborative.  So it might be nice to be able to specify
permission/uid/gid policies that do a configurable level of munging
for stuff passed into and out of the index and/or the repositories.

I also never understood why there were no permissions set on
directories in trees...

Because directories are not actually tracked.  They are created and
deleted as-needed.

In my proposal for allowing directories to get tracked, permissions of
000 would indicate a tree without a corresponding tracked directory.
Other permissions would correspond to a tracked directory.  I am still
stuck over the representation in the index.

One idea is to unconditionally have an entry "dirname" without
permissions, and optionally "dirname/" with permissions iff the
directory is supposed to be tracked, both to be sorted in
alphabetically.  The idea of the first entry is being able to detect
merge conflicts without extra passes.

But I have not worked on the stuff for a while.

nor why, while the sha1 for child objects are "packed", the modes
aren't...

Because a change of the mode of a file will then not cause different
sha1 sums at the file level.

-- 
David Kastrup

On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup [off-list ref] wrote:

quoted

I also never understood why there were no permissions set on
directories in trees...

Because directories are not actually tracked.  They are created and
deleted as-needed.

I don't see why it would prevent to have a permission set to it... the
permission technically can be recorded in the parent tree, along its
sha1. Filesystems are also like this.

In my proposal for allowing directories to get tracked, permissions of
000 would indicate a tree without a corresponding tracked directory.
Other permissions would correspond to a tracked directory.  I am still
stuck over the representation in the index.

One idea is to unconditionally have an entry "dirname" without
permissions, and optionally "dirname/" with permissions iff the
directory is supposed to be tracked, both to be sorted in
alphabetically.  The idea of the first entry is being able to detect
merge conflicts without extra passes.

But I have not worked on the stuff for a while.

I don't see why you would need an additional entry for the directory
permission.

quoted

nor why, while the sha1 for child objects are "packed", the modes
aren't...

Because a change of the mode of a file will then not cause different
sha1 sums at the file level.

I think i wasn't clear enough... I just wondered why the format for tree
entries is something like (if you'd write it in perl):
sprintf "%06o %s\0%s", $mode, $file, pack("H[40]", $sha1)

Mike

martin f krafft, Mon, Aug 20, 2007 18:44:11 +0200:

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. ...

Git tracks just the x-bit. Everything else is controlled by your
umask.

Symlinks are supported since long time.

As noted by Mike Hommey, the documentation for the config setting tar.umask
is not up-to-date.  Commit f08b3b0e2e9ad87767d80ff03b013c686e08ba4b changed
the default from 0 to 2; this patch finally documents it.

Signed-off-by: Rene Scharfe <redacted>
---

diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 4da07c1..9984a11 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt

@@ -80,8 +80,8 @@ in the repository configuration as follows :
         umask = 002	;# group friendly
 
 The special umask value "user" indicates that the user's current umask
-will be used instead. The default value remains 0, which means world
-readable/writable files and directories.
+will be used instead.  The default is 002, which allows reading for all
+and writing for both owner and group.
 
 EXAMPLES
 --------

Mike Hommey schrieb:

On Mon, Aug 20, 2007 at 06:44:11PM +0200, martin f krafft [off-list ref] wrote:

quoted

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

Same applies to git-archive, which generates files with mode 666 and
directories with 777, while it could follow the modes in the
repository... or at least, that's what the manpage claims, but facts
seem to be quite different...

mh@namakemono:~/git/git$ git-archive --format=tar HEAD | tar -tvf -
-rw-rw-r-- root/root      2365 2007-08-19 20:45 .gitignore
-rw-rw-r-- root/root      1973 2007-08-19 20:45 .mailmap
-rw-rw-r-- root/root     18787 2007-08-19 20:45 COPYING
drwxrwxr-x root/root         0 2007-08-19 20:45 Documentation/

mh@namakemono:~/git/git$ umask
0022

And no value is set for umask in git config...

In that case the default value for tar.umask applies, which is 002.  The
manpage needs an update..  Thanks for spotting this.

You can set it to 022 explicitly or to "user" to restrict permissions:

   $ git config tar.umask 022		# -rw-r--r--
   $ git config tar.umask user		# your Unix umask applies

Originally file permissions were simply copied into the archive, but
this was inconvenient for users that needed more permission bits set,
e.g. to share an extracted archive with with others by default.

Also please note that tar applies your umask when extracting files
(exception: GNU tar doesn't do that by default if run as root), so the
permissions of extracted files may look different from the output of
"tar -t".

René

On Tue, Aug 21, 2007 at 08:01:16PM +0200, René Scharfe [off-list ref] wrote:

Actually, I'd say it's not enough ; users may be confused by the
sentence just above:

By default, file and directories modes are set to 0666 or 0777 in tar
archives.

Which is true, but if you are not very familiar with umask, you won't
actually gather from the rest that the modes are not going to be that by
default.

Mike

On Aug 20, 2007, at 6:44 PM, martin f krafft wrote:

Hello,

I am a bit confused about how git stores and restores permissions.

[...]

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,

Hi,
this thread drifted away and although the discussion is interesting,  
the original question hasn't been answered so far and I am in a  
situation where I'd like to know the answer (because my working tree  
needs to be group-readable for a given project and my umask 066 keeps  
annoying me although I don't want to change it).

Someone on IRC pointed me to http://git.or.cz/gitwiki/ 
ContentLimitations which says:

"By design, git cannot track other aspects of the filesystem, including:
   * File modes (except for the "executable" bit, and being symbolic  
link)"

That's weird since the file mode is saved in the tree, isn't there a  
way to ask Git to restore this file mode?

Cheers,

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Benoit SIGOURE wrote:

this thread drifted away and although the discussion is interesting,
the original question hasn't been answered so far and I am in a
situation where I'd like to know the answer (because my working tree
needs to be group-readable for a given project and my umask 066 keeps
annoying me although I don't want to change it).

Someone on IRC pointed me to http://git.or.cz/gitwiki/
ContentLimitations which says:

"By design, git cannot track other aspects of the filesystem, including:
   * File modes (except for the "executable" bit, and being symbolic
link)"

That's weird since the file mode is saved in the tree, isn't there a
way to ask Git to restore this file mode?

At this time, there is not. git tracks only the executable bit. Even
though it stores (and reports) the complete mode, it only ever stores
one of these mode values: 100644, 100755, 120000. Yes, that's an
enormous waste of bits, but that's how it is.

-- Hannes

Mike Hommey schrieb:

Actually, I'd say it's not enough ; users may be confused by the
sentence just above:

By default, file and directories modes are set to 0666 or 0777 in tar
archives.

Which is true, but if you are not very familiar with umask, you won't
actually gather from the rest that the modes are not going to be that by
default.

Hmm.  And I forgot to update two other places.  How about this?  Too short?

 Documentation/config.txt       |   14 +++++---------
 Documentation/git-archive.txt  |   15 ++++++---------
 Documentation/git-tar-tree.txt |   15 ++++++---------
 3 files changed, 17 insertions(+), 27 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 46f40ad..462595c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt

@@ -675,15 +675,11 @@ showbranch.default::
 	See gitlink:git-show-branch[1].
 
 tar.umask::
-	By default, gitlink:git-tar-tree[1] sets file and directories modes
-	to 0666 or 0777. While this is both useful and acceptable for projects
-	such as the Linux Kernel, it might be excessive for other projects.
-	With this variable, it becomes possible to tell
-	gitlink:git-tar-tree[1] to apply a specific umask to the modes above.
-	The special value "user" indicates that the user's current umask will
-	be used. This should be enough for most projects, as it will lead to
-	the same permissions as gitlink:git-checkout[1] would use. The default
-	value remains 0, which means world read-write.
+	This variable can be used to restrict the permission bits of
+	tar archive entries.  The default is 0002, which turns off the
+	world write bit.  The special value "user" indicates that the
+	archiving user's umask will be used instead.  See umask(2) and
+	gitlink:git-archive[1].
 
 user.email::
 	Your email address to be recorded in any newly created commits.

diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 4da07c1..f2080eb 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt

@@ -72,16 +72,13 @@ zip
 
 CONFIGURATION
 -------------
-By default, file and directories modes are set to 0666 or 0777 in tar
-archives.  It is possible to change this by setting the "umask" variable
-in the repository configuration as follows :
 
-[tar]
-        umask = 002	;# group friendly
-
-The special umask value "user" indicates that the user's current umask
-will be used instead. The default value remains 0, which means world
-readable/writable files and directories.
+tar.umask::
+	This variable can be used to restrict the permission bits of
+	tar archive entries.  The default is 0002, which turns off the
+	world write bit.  The special value "user" indicates that the
+	archiving user's umask will be used instead.  See umask(2) for
+	details.
 
 EXAMPLES
 --------

diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index 2d01d96..434607b 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt

@@ -42,16 +42,13 @@ OPTIONS
 
 CONFIGURATION
 -------------
-By default, file and directories modes are set to 0666 or 0777. It is
-possible to change this by setting the "umask" variable in the
-repository configuration as follows :
 
-[tar]
-        umask = 002	;# group friendly
-
-The special umask value "user" indicates that the user's current umask
-will be used instead.  The default value is 002, which means group
-readable/writable files and directories.
+tar.umask::
+	This variable can be used to restrict the permission bits of
+	tar archive entries.  The default is 0002, which turns off the
+	world write bit.  The special value "user" indicates that the
+	archiving user's umask will be used instead.  See umask(2) for
+	details.
 
 EXAMPLES
 --------