preserve permissions?

preserve permissions?

[Jonathan Chetwynd]

git clone ../xsl-test/

the original has a single directory, owner _www, and a few files.

however the clone directory has owner Me.

what is the reason permissions are not preserved?

regards

Jonathan Chetwynd

testing git before moving a development project to git for production

Re: preserve permissions?

[Jakub Narebski]

Jonathan Chetwynd <j.chetwynd@btinternet.com> writes:

> git clone ../xsl-test/
> 
> the original has a single directory, owner _www, and a few files.
> 
> however the clone directory has owner Me.
> 
> what is the reason permissions are not preserved?

Why should permissions be preserved?  Git is a version control system,
meant mainly for software management, not a backup system.  

When you clone repository from somebody, you don't want for files to
have that somebody ownership, especially that such user most probably
do not exist on your machine.

Therefore git does not store ownership, and only basic permissions
(only executable bit for ordinary files, and the symlink bit).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: preserve permissions?

[Andrew Keller]

On May 4, 2010, at 8:29 AM, Jonathan Chetwynd wrote:

> ...
> 
> what is the reason permissions are not preserved?
> 
> ...


Git implements a network of trust permission model.  In this model, system permissions are used (among other things) to control who has access to a repository.  Once someone has access, they can perform a clone or a fetch.  This process downloads refs into a local repository that inherits your local permissions.  This model is simple, but it is often capable of most things that system permissions can do, and it avoids the problem of a given user in the repository not existing on a machine.

One of the implications of this model is that although system permissions can be used to control who has access to a repository, they are not stored in the repository itself.  This means that if you clone a repository, the system permissions of the repository are never preserved.  This is a very intentional detail of the network of trust permission model.  Once a user has access to a repository, that user has access to the whole repository.  It is exactly like telling another person something.  Once the other person hears the data, that person can do whatever he or she wants with it.  He or she "owns" a copy of the data.

In other words, if you want a user X to own a repository upon cloning, then user X must be the one to perform the clone.  If you want Sue to know that the new kitchen table is made of oak, then Sue must be the one to ask the question (aka clone or fetch).  You cannot ask the question for Sue and expect her to instantly know what you know.

HTH
~ Andrew Keller

Re: preserve permissions?

[snk]

> Therefore git does not store ownership, and only basic permissions 
> (only executable bit for ordinary files, and the symlink bit). 

Fine.  "git diff" reports wrong new permissions though: 755 instead of 764. 

shanker@linux-0tix:~/test/play2> git reset --hard HEAD
HEAD is now at 85d4483 test
shanker@linux-0tix:~/test/play2> git config core.filemode
true
shanker@linux-0tix:~/test/play2> ls -l x
-rw-rw-r-- 1 shanker users 0 Mar  3 11:00 x
shanker@linux-0tix:~/test/play2> chmod u+x x
shanker@linux-0tix:~/test/play2> git diff x
diff --git a/x b/x
old mode 100644
new mode 100755
shanker@linux-0tix:~/test/play2> ls -l x
-rwxrw-r-- 1 shanker users 0 Mar  3 11:00 x
shanker@linux-0tix:~/test/play2> 


--
View this message in context: http://git.661346.n2.nabble.com/preserve-permissions-tp5003065p7340464.html
Sent from the git mailing list archive at Nabble.com.

Re: preserve permissions?

[Jakub Narebski]

snk <shank76@gmail.com> writes:

> > Therefore git does not store ownership, and only basic permissions 
> > (only executable bit for ordinary files, and the symlink bit). 
> 
> Fine.  "git diff" reports wrong new permissions though: 755 instead of 764. 

"Executable bit" is not "executable permissions"
 
> shanker@linux-0tix:~/test/play2> git reset --hard HEAD
> HEAD is now at 85d4483 test
> shanker@linux-0tix:~/test/play2> git config core.filemode
> true
> shanker@linux-0tix:~/test/play2> ls -l x
> -rw-rw-r-- 1 shanker users 0 Mar  3 11:00 x
> shanker@linux-0tix:~/test/play2> chmod u+x x
> shanker@linux-0tix:~/test/play2> git diff x
> diff --git a/x b/x
> old mode 100644
> new mode 100755
> shanker@linux-0tix:~/test/play2> ls -l x
> -rwxrw-r-- 1 shanker users 0 Mar  3 11:00 x
> shanker@linux-0tix:~/test/play2> 

Git stores only whether file is executable or not.  To be more exact
git uses only a few modes: one for submodule (commit), one for
directory, one for symbolic link, one for ordinary executable file,
and one for ordinary file (non-executable).

-- 
Jakub Narebski