On Sat, 6 Dec 2008, jidanni@xxxxxxxxxxx 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* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
