why not preserve file permissions?

why not preserve file permissions?

[jidanni]

Why not preserve permissions the way you find them, instead of just
using 644 and 755? It certainly couldn't be more complicated than what
you are doing now, and that way one could do things like use git to
update system administration files across a sneakernet containing e.g.,
# dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u
-rw-r-----
-rw-r--r--
-rwxr-xr-x

> git was made for tracking source code, not 640 files.

On the sneakernet no public patches would be sent, and the
administrator would remember to make the sensitive .git directories
700. And sure, git should enforce umask or no set-uid or whatever when
doing a checkout etc. The deluxe edition of git could even print a
warning: "you are trying to track a 640 file but your .git permissions
are less restrictive." However I recommend no premium or deluxe
editions for now.

> Patches welcome.

Trust me, you don't want "grandpa who forgot the parking brake"
anywhere near your code.

Re: why not preserve file permissions?

[Jakub Narebski]

jidanni@jidanni.org writes:

> Why not preserve permissions the way you find them, instead of just
> using 644 and 755? It certainly couldn't be more complicated than what
> you are doing now, and that way one could do things like use git to
> update system administration files across a sneakernet containing e.g.,
> # dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u
> -rw-r-----
> -rw-r--r--
> -rwxr-xr-x
> 
> > git was made for tracking source code, not 640 files.
> 
> On the sneakernet no public patches would be sent, and the
> administrator would remember to make the sensitive .git directories
> 700. And sure, git should enforce umask or no set-uid or whatever when
> doing a checkout etc. The deluxe edition of git could even print a
> warning: "you are trying to track a 640 file but your .git permissions
> are less restrictive." However I recommend no premium or deluxe
> editions for now.

Git was made for tracking _source code_ among _different_ machines, as
a way to collaborate in development.  This means that different users
of the same repository can have and usually have different user,
different user-id, different group, and perhaps different group
permission settings on a files.  Git supports only ordinary files,
executable ordinary files, directories and symbolic links for
a reason: otherwise it would be very easy to propagate spurious
permission changes because some contributor has different setup.

Side note: git can be used on operating systems / with filesystems
which do not have UNIX notion of permissions (think MS Windows).


Also changes _now_ to the repository format (and keeping full
permissions would require changing format of 'tree' objects) would
have to be extremely well substantiated.  And using git to store
system administration files, as a kind of cross between (amost) single
machine version control and backup system is possible even now: see
Etckeeper and IsiSetup tools (you can find them at git wiki at
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools page).  Or you
can use tools like CFEngine...

HTH.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: why not preserve file permissions?

[Junio C Hamano]

jidanni@jidanni.org writes:

> Why not preserve permissions the way you find them, instead of just
> using 644 and 755? It certainly couldn't be more complicated than what
> you are doing now, and that way one could do things like use git to
> update system administration files across a sneakernet containing e.g.,
> # dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u
> -rw-r-----
> -rw-r--r--
> -rwxr-xr-x

Actually in a very early days, git used to record the full (mode & 0777)
for blobs.

Once people started using git, everybody realized that it had a very
unpleasant side effect that the resulting tree depended on user's umasks,
because one person records a blob with mode 664 and the next person who
modifies the file would record with mode 644, and it made it very hard to
keep track of meaningful changes to the source code.  This issue was fixed
long time ago with commit e447947 (Be much more liberal about the file
mode bits., 2005-04-16).

Re: why not preserve file permissions?

[Jeff King]

On Fri, Dec 05, 2008 at 02:38:41PM -0800, Junio C Hamano wrote:

> Actually in a very early days, git used to record the full (mode & 0777)
> for blobs.
> 
> Once people started using git, everybody realized that it had a very
> unpleasant side effect that the resulting tree depended on user's umasks,

Note, of course that "everybody" in your sentence is "everybody who was
using git as a source control mechanism." I think as git has grown,
people have wanted to use it to version other things, such as dot files
in their home directory or the contents of /etc, two situations where
file metadata might be of as much interest as the file content.

And I don't see a real problem in a config switch or two to handle a
vastly different workflow like that, if it can be done with minimal
intrusion. For example, now we throw away most of the mode bits; it
would probably only be a few lines of code difference to keep those mode
bits, people who turned on that config option would presumably know what
they are doing, and performance for the usual workflow would be
unaffected.

_But_ I think people who ask for just permission bits aren't really
thinking things through. Those bits are only one part of the metadata.
There's file owner and group. There are timestamps. There are
non-regular files with their own associated metadata (like major/minor
device numbers). There are extended attributes, which covers things like
ACLs (and I don't even know if there's a standard representation that
can cover the ACLs for all platforms we support).

And those things _aren't_ as easy as flipping a config switch. They mean
changes to the fundamental data structures of git, and all of the pain
that entails: a lot of code, interoperability annoyances, and probably
performance impacts for unrelated workflows.

So I am sympathetic to somebody who, after thinking it through, has a
use case that just requires tracking permissions bits and wants a config
option for git to do that. But the commonly given examples seem much
better served by a _full_ metadata solution that lives on top of git,
like metastore. I haven't seen a compelling argument for just handling
permission bits.

-Peff

Re: why not preserve file permissions?

[Daniel Barkalow]

On Sat, 6 Dec 2008, jidanni@jidanni.org wrote:

> Why not preserve permissions the way you find them, instead of just
> using 644 and 755? It certainly couldn't be more complicated than what
> you are doing now, and that way one could do things like use git to
> update system administration files across a sneakernet containing e.g.,
> # dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u
> -rw-r-----
> -rw-r--r--
> -rwxr-xr-x
> 
> > git was made for tracking source code, not 640 files.
> 
> On the sneakernet no public patches would be sent, and the
> administrator would remember to make the sensitive .git directories
> 700. And sure, git should enforce umask or no set-uid or whatever when
> doing a checkout etc. The deluxe edition of git could even print a
> warning: "you are trying to track a 640 file but your .git permissions
> are less restrictive." However I recommend no premium or deluxe
> editions for now.

The fundamental issue is that git is intended to support development, 
which is to say that users have to be able to create trees that reflect 
the content that they intend the project to have, rather than only content 
that they can represent directly in their working tree. In order to do 
development on an exim configuration, you may want to be able to set 
permissions and ownership that will only make sense in the production 
environment. So it's actually better to have some setup where you've got a 
metadata file (that you can make arbitrary changes to without any 
particular hassle) in addition to the content files, and a script for 
putting the files in place with the metadata applied on the live server.

That is, preserving metadata would allow you to use git as a really 
complicated version of tar, but wouldn't give you the advantages of using 
git.

	-Daniel
*This .sig left intentionally blank*