{"thread":{"id":"9593","subject":"confused about preserved permissions","startedAt":"2007-08-20T16:44:11Z","lastAt":"2007-09-03T18:59:16Z","messageCount":39,"participants":["martin f krafft","Pierre Habouzit","Mike Hommey","David Kastrup","Alex Riesen","Jan Hudec","Shawn O. Pearce","Junio C Hamano","René Scharfe","Benoit SIGOURE","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51092","messageId":"20070820164411.GA15637@piper.oerlikon.madduck.net","threadId":"9593","inReplyTo":null,"subject":"confused about preserved permissions","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-20T16:44:11Z","receivedAt":"2007-08-20T16:44:11Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Hello,\n\nI am a bit confused about how git stores and restores permissions.\nI went to the web but found little other than this post from Linus\nin 2005:\n\n http://www.gelato.unsw.edu.au/archives/git/0504/0870.html\n\nwhere he basically says that git will *not* save permissions and\nthat it also does not save symlinks. I thus discarded the\ninformation as being outdated. I have also looked into the source,\nbut the following question is more about git design than\nimplementation.\n\nLet me illustrate the source of my confusion:\n\n $ git init\n Initialized empty Git repository in .git/\n $ umask\n 002\n $ date > file1; ls -l file1\n -rw-rw-r-- 1 madduck madduck 30 2007-08-20 18:15 file1\n $ git add file1; git commit -m.\n Created initial commit 5762460: .\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 file1\n\nfile1 is mode 664, but gut says \"create mode 100644 file1\",\nindependently of whether I use --shared when initialising, or what\nvalue I set it to. Why does it override the group write bit?\n\nBut it gets worse:\n\n $ git checkout -b t\n Switched to a new branch \"t\"\n $ git rm file1; git commit -m.\n rm 'file1'\n Created commit a813b4e: .\n 1 files changed, 0 insertions(+), 1 deletions(-)\n delete mode 100644 file1\n $ umask 007\n $ git checkout master\n Switched to branch \"master\"\n $ ls -l file1\n -rw-rw---- 1 madduck madduck 30 2007-08-20 18:15 file1\n\nSo git doesn't even restore 644 when I switch branches, nor on\ninitial clone, or on re-checkout after removing the local copy.\n\nAm I doing something wrong?\n\nWhy does git bother saving a mode when later it never seems to use\nit again?\n\nAnd is there a way to tell git not to mess with the permissions in\nthe worktree when switching branches? I am not sure what's causing\nit since the inode of files does not seem to change, so git\napparently explicitly fchmod()'s files.\n\nI'd be grateful for any documentation to read in addition to the\ncode. I saw core.filemode, but that's only about the x bit, it\nseems.\n\nThanks,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"vista is evidentally latvian for \"hen\", and \"perating system\", that\n is, OS without the o, means \"system for making eggs.\" so vista is at\n least useful come breakfast time?\"\n -- kit la touche\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"51093","messageId":"20070820165426.GA7206@artemis.corp","threadId":"9593","inReplyTo":"20070820164411.GA15637@piper.oerlikon.madduck.net","subject":"Re: confused about preserved permissions","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-08-20T16:54:26Z","receivedAt":"2007-08-20T16:54:26Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Aug 20, 2007 at 04:44:11PM +0000, martin f krafft wrote:\n> I'd be grateful for any documentation to read in addition to the\n> code. I saw core.filemode, but that's only about the x bit, it\n> seems.\n\n You may want to read git-config around core.sharedRepository.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"51097","messageId":"20070820173840.GA19868@piper.oerlikon.madduck.net","threadId":"9593","inReplyTo":"20070820165426.GA7206@artemis.corp","subject":"Re: confused about preserved permissions","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-20T17:38:40Z","receivedAt":"2007-08-20T17:38:40Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Pierre Habouzit [2007.08.20.1854 +0200]:\n> > I'd be grateful for any documentation to read in addition to the\n> > code. I saw core.filemode, but that's only about the x bit, it\n> > seems.\n> \n> You may want to read git-config around core.sharedRepository.\n\nHello Pierre, thanks for taking the time to respond.\n\ncore.sharedRepository (or init --shared for that matter) seems to\nonly deal with permissions of $GIT_DIR. I am worrying about the\npermissions of the worktree. I also stated in the OP that I had used\n--shared but none of the settings made any difference...\n\nCheers,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nnormaliser unix c'est comme pasteuriser le camembert.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"51099","messageId":"20070820174142.GA7943@glandium.org","threadId":"9593","inReplyTo":"20070820164411.GA15637@piper.oerlikon.madduck.net","subject":"Re: confused about preserved permissions","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-20T17:41:42Z","receivedAt":"2007-08-20T17:41:42Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Aug 20, 2007 at 06:44:11PM +0200, martin f krafft wrote:\n> Why does git bother saving a mode when later it never seems to use\n> it again?\n\nSame applies to git-archive, which generates files with mode 666 and\ndirectories with 777, while it could follow the modes in the\nrepository... or at least, that's what the manpage claims, but facts\nseem to be quite different...\n\nmh@namakemono:~/git/git$ git-archive --format=tar HEAD | tar -tvf -\n-rw-rw-r-- root/root 2365 2007-08-19 20:45 .gitignore\n-rw-rw-r-- root/root 1973 2007-08-19 20:45 .mailmap\n-rw-rw-r-- root/root 18787 2007-08-19 20:45 COPYING\ndrwxrwxr-x root/root 0 2007-08-19 20:45 Documentation/\n-rw-rw-r-- root/root 63 2007-08-19 20:45 Documentation/.gitignore\n-rw-rw-r-- root/root 4553 2007-08-19 20:45 Documentation/Makefile\n(...)\nmh@namakemono:~/git/git$ git-ls-tree HEAD\n100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c .gitignore\n100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d .mailmap\n100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3 COPYING\n040000 tree 865a32f4b417cbb601524ac2b78ca64ff232302c Documentation\n100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200 GIT-VERSION-GEN\n(...)\n\nmh@namakemono:~/git/git$ umask\n0022\n\nAnd no value is set for umask in git config...\n\nI also never understood why there were no permissions set on directories\nin trees... nor why, while the sha1 for child objects are \"packed\", the\nmodes aren't...\n\nMike\n"},{"id":"51101","messageId":"867inqhyuk.fsf@lola.quinscape.zz","threadId":"9593","inReplyTo":"20070820174142.GA7943@glandium.org","subject":"Re: confused about preserved permissions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-20T17:58:43Z","receivedAt":"2007-08-20T17:58:43Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Mike Hommey writes:\n\n> On Mon, Aug 20, 2007 at 06:44:11PM +0200, martin f krafft wrote:\n>> Why does git bother saving a mode when later it never seems to use\n>> it again?\n>\n> Same applies to git-archive, which generates files with mode 666 and\n> directories with 777, while it could follow the modes in the\n> repository... or at least, that's what the manpage claims, but facts\n> seem to be quite different...\n\nGit had permissions at one point of time. It makes colloboration with\nother people with different umasks a nuisance. However, not all uses\nare colloborative. So it might be nice to be able to specify\npermission/uid/gid policies that do a configurable level of munging\nfor stuff passed into and out of the index and/or the repositories.\n\n> I also never understood why there were no permissions set on\n> directories in trees...\n\nBecause directories are not actually tracked. They are created and\ndeleted as-needed.\n\nIn my proposal for allowing directories to get tracked, permissions of\n000 would indicate a tree without a corresponding tracked directory.\nOther permissions would correspond to a tracked directory. I am still\nstuck over the representation in the index.\n\nOne idea is to unconditionally have an entry \"dirname\" without\npermissions, and optionally \"dirname/\" with permissions iff the\ndirectory is supposed to be tracked, both to be sorted in\nalphabetically. The idea of the first entry is being able to detect\nmerge conflicts without extra passes.\n\nBut I have not worked on the stuff for a while.\n\n> nor why, while the sha1 for child objects are \"packed\", the modes\n> aren't...\n\nBecause a change of the mode of a file will then not cause different\nsha1 sums at the file level.\n\n-- \nDavid Kastrup\n"},{"id":"51104","messageId":"20070820181357.GA8264@glandium.org","threadId":"9593","inReplyTo":"867inqhyuk.fsf@lola.quinscape.zz","subject":"Re: confused about preserved permissions","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-20T18:13:57Z","receivedAt":"2007-08-20T18:13:57Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup wrote:\n> > I also never understood why there were no permissions set on\n> > directories in trees...\n> \n> Because directories are not actually tracked. They are created and\n> deleted as-needed.\n\nI don't see why it would prevent to have a permission set to it... the\npermission technically can be recorded in the parent tree, along its\nsha1. Filesystems are also like this.\n\n> In my proposal for allowing directories to get tracked, permissions of\n> 000 would indicate a tree without a corresponding tracked directory.\n> Other permissions would correspond to a tracked directory. I am still\n> stuck over the representation in the index.\n> \n> One idea is to unconditionally have an entry \"dirname\" without\n> permissions, and optionally \"dirname/\" with permissions iff the\n> directory is supposed to be tracked, both to be sorted in\n> alphabetically. The idea of the first entry is being able to detect\n> merge conflicts without extra passes.\n> \n> But I have not worked on the stuff for a while.\n\nI don't see why you would need an additional entry for the directory\npermission.\n\n> > nor why, while the sha1 for child objects are \"packed\", the modes\n> > aren't...\n> \n> Because a change of the mode of a file will then not cause different\n> sha1 sums at the file level.\n\nI think i wasn't clear enough... I just wondered why the format for tree\nentries is something like (if you'd write it in perl):\nsprintf \"%06o %s\\0%s\", $mode, $file, pack(\"H[40]\", $sha1)\n\nMike\n"},{"id":"51107","messageId":"20070820183511.GA5544@steel.home","threadId":"9593","inReplyTo":"20070820164411.GA15637@piper.oerlikon.madduck.net","subject":"Re: confused about preserved permissions","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-08-20T18:35:11Z","receivedAt":"2007-08-20T18:35:11Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"martin f krafft, Mon, Aug 20, 2007 18:44:11 +0200:\n> Hello,\n> \n> I am a bit confused about how git stores and restores permissions.\n> I went to the web but found little other than this post from Linus\n> in 2005:\n> \n> http://www.gelato.unsw.edu.au/archives/git/0504/0870.html\n> \n> where he basically says that git will *not* save permissions and\n> that it also does not save symlinks. I thus discarded the\n> information as being outdated. ...\n\nGit tracks just the x-bit. Everything else is controlled by your\numask.\n\nSymlinks are supported since long time.\n"},{"id":"51109","messageId":"86r6lygi6f.fsf@lola.quinscape.zz","threadId":"9593","inReplyTo":"20070820181357.GA8264@glandium.org","subject":"Re: confused about preserved permissions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-20T18:44:08Z","receivedAt":"2007-08-20T18:44:08Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Mike Hommey writes:\n\n> On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup wrote:\n>> > I also never understood why there were no permissions set on\n>> > directories in trees...\n>> \n>> Because directories are not actually tracked. They are created and\n>> deleted as-needed.\n>\n> I don't see why it would prevent to have a permission set to\n> it... the permission technically can be recorded in the parent tree,\n> along its sha1. Filesystems are also like this.\n\nNo, they aren't. Filesystems don't create and delete directories on\nthe fly. If we record any information about a directory, deleting it\nautomagically would not be appropriate since we would lose information\nthat has not been explicitly deleted.\n\n>> Other permissions would correspond to a tracked directory. I am still\n>> stuck over the representation in the index.\n>> \n>> One idea is to unconditionally have an entry \"dirname\" without\n>> permissions, and optionally \"dirname/\" with permissions iff the\n>> directory is supposed to be tracked, both to be sorted in\n>> alphabetically. The idea of the first entry is being able to detect\n>> merge conflicts without extra passes.\n>> \n>> But I have not worked on the stuff for a while.\n>\n> I don't see why you would need an additional entry for the directory\n> permission.\n\nOne doesn't. It would be just there to facilitate single-pass\ndetection of merge conflicts. No non-redundant information content to\nit at all, but it delivers the \"we'll need a directory here\"\ninformation earlier in the sort order.\n\nBut one can probably do without that by just stashing away\nnon-directory entries namex* possibly colliding with a tree until the\nopportunity for namex/* has passed by, and then processing them. That\nmakes for a cleaner index format.\n\nThere is still the question when one stores just a single entry\nwhether to sort this under \"namex\" or \"namex/\" and whether to also\nhave it appear when it corresponds to a non-tracked directory.\n\nIt does not really make sense settling on one format before one\nimplements the various merge/update/checkout utilities since then one\nsees what is most convenient.\n\n>> > nor why, while the sha1 for child objects are \"packed\", the modes\n>> > aren't...\n>> \n>> Because a change of the mode of a file will then not cause different\n>> sha1 sums at the file level.\n>\n> I think i wasn't clear enough... I just wondered why the format for tree\n> entries is something like (if you'd write it in perl):\n> sprintf \"%06o %s\\0%s\", $mode, $file, pack(\"H[40]\", $sha1)\n\nNow I am sure I don't get your point.\n\n-- \nDavid Kastrup\n"},{"id":"51110","messageId":"20070820184829.GA8617@glandium.org","threadId":"9593","inReplyTo":"86zm0mgicy.fsf@lola.quinscape.zz","subject":"Re: confused about preserved permissions","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-20T18:48:29Z","receivedAt":"2007-08-20T18:48:29Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Aug 20, 2007 at 08:40:13PM +0200, David Kastrup wrote:\n> Mike Hommey writes:\n> \n> > On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup wrote:\n> >> > I also never understood why there were no permissions set on\n> >> > directories in trees...\n> >> \n> >> Because directories are not actually tracked. They are created and\n> >> deleted as-needed.\n> >\n> > I don't see why it would prevent to have a permission set to\n> > it... the permission technically can be recorded in the parent tree,\n> > along its sha1. Filesystems are also like this.\n> \n> No, they aren't. Filesystems don't create and delete directories on\n> the fly. If we record any information about a directory, deleting it\n> automagically would not be appropriate since we would lose information\n> that has not been explicitly deleted.\n\ngit doesn't magically create directories either. It actually stores\nsomething about them: the hash of the tree object that represents them.\nAnd it has permissions associated with these hashes.\n\nWhat it doesn't have, though, is tracking of the directory's history.\n\n(...)\n> > I think i wasn't clear enough... I just wondered why the format for tree\n> > entries is something like (if you'd write it in perl):\n> > sprintf \"%06o %s\\0%s\", $mode, $file, pack(\"H[40]\", $sha1)\n> \n> Now I am sure I don't get your point.\n\nSee what a raw tree object looks like:\ngit-cat-file tree 708453d64796eb617cb8a1602959e00356693315\n\nMike\n"},{"id":"51114","messageId":"20070820194328.GE8542@efreet.light.src","threadId":"9593","inReplyTo":"20070820184829.GA8617@glandium.org","subject":"Re: confused about preserved permissions","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-08-20T19:43:28Z","receivedAt":"2007-08-20T19:43:28Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Aug 20, 2007 at 20:48:29 +0200, Mike Hommey wrote:\n> On Mon, Aug 20, 2007 at 08:40:13PM +0200, David Kastrup wrote:\n> > Mike Hommey writes:\n> > \n> > > On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup wrote:\n> > >> > I also never understood why there were no permissions set on\n> > >> > directories in trees...\n> > >> \n> > >> Because directories are not actually tracked. They are created and\n> > >> deleted as-needed.\n> > >\n> > > I don't see why it would prevent to have a permission set to\n> > > it... the permission technically can be recorded in the parent tree,\n> > > along its sha1. Filesystems are also like this.\n> > \n> > No, they aren't. Filesystems don't create and delete directories on\n> > the fly. If we record any information about a directory, deleting it\n> > automagically would not be appropriate since we would lose information\n> > that has not been explicitly deleted.\n> \n> git doesn't magically create directories either. It actually stores\n> something about them: the hash of the tree object that represents them.\n> And it has permissions associated with these hashes.\n> \n> What it doesn't have, though, is tracking of the directory's history.\n\nGit does not have tracking of file's history either.\n\nThere are actually no permissions to record with a directory, since only\nexecutable bit is tracked and that always has to be turned on.\n\nGit actually does store directories in tree objects, but never in the index.\nThere was a long thread about tracking existence of directories. IMNSHO the\nindex can start to *always* contain directories, with reader being able to\ndetect index written without them and automatically fill them in, to keep\ncompatibility. Than a config option could switch between removing empty\ndirectories implicitly when there are no versioned files in them, or\nexplicitely.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"51115","messageId":"20070820195037.GA9774@glandium.org","threadId":"9593","inReplyTo":"20070820194328.GE8542@efreet.light.src","subject":"Re: confused about preserved permissions","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-20T19:50:37Z","receivedAt":"2007-08-20T19:50:37Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Aug 20, 2007 at 09:43:28PM +0200, Jan Hudec wrote:\n> Git does not have tracking of file's history either.\n\nWell, it has ways to track file's history, with blame and log, for\nexample. There is nothing similar for directories, though it could be\npossible to do.\n\nMike\n"},{"id":"51119","messageId":"20070820200719.GE5544@steel.home","threadId":"9593","inReplyTo":"20070820195037.GA9774@glandium.org","subject":"Re: confused about preserved permissions","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-08-20T20:07:19Z","receivedAt":"2007-08-20T20:07:19Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Mike Hommey, Mon, Aug 20, 2007 21:50:37 +0200:\n> On Mon, Aug 20, 2007 at 09:43:28PM +0200, Jan Hudec wrote:\n> > Git does not have tracking of file's history either.\n> \n> Well, it has ways to track file's history, with blame and log, for\n> example. There is nothing similar for directories, though it could be\n> possible to do.\n\nIt would be not exactly \"tracking\". You can present the history of\nchanges which involved the said directory.\n\nAnd you could do it from day one: git log -- sub/dir\n"},{"id":"51120","messageId":"20070820200815.GG8542@efreet.light.src","threadId":"9593","inReplyTo":"20070820195037.GA9774@glandium.org","subject":"Re: confused about preserved permissions","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-08-20T20:08:15Z","receivedAt":"2007-08-20T20:08:15Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Aug 20, 2007 at 21:50:37 +0200, Mike Hommey wrote:\n> On Mon, Aug 20, 2007 at 09:43:28PM +0200, Jan Hudec wrote:\n> > Git does not have tracking of file's history either.\n> \n> Well, it has ways to track file's history, with blame and log, for\n> example. There is nothing similar for directories, though it could be\n> possible to do.\n\nNeither of them is file's history. They dig in the global history for\nrecords, that are, by some heuristic, related to something. Blame really\nlooks for a bunch of lines and log looks for given path (can be whole\nsubtree).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"51122","messageId":"20070820201042.GA9942@glandium.org","threadId":"9593","inReplyTo":"20070820200719.GE5544@steel.home","subject":"Re: confused about preserved permissions","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-20T20:10:42Z","receivedAt":"2007-08-20T20:10:42Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Aug 20, 2007 at 10:07:19PM +0200, Alex Riesen wrote:\n> Mike Hommey, Mon, Aug 20, 2007 21:50:37 +0200:\n> > On Mon, Aug 20, 2007 at 09:43:28PM +0200, Jan Hudec wrote:\n> > > Git does not have tracking of file's history either.\n> > \n> > Well, it has ways to track file's history, with blame and log, for\n> > example. There is nothing similar for directories, though it could be\n> > possible to do.\n> \n> It would be not exactly \"tracking\". You can present the history of\n> changes which involved the said directory.\n> \n> And you could do it from day one: git log -- sub/dir\n\nIt could be possible to really do tracking, too, like it is possible for\nfiles (including renames, moves, etc.)\n\nMike\n"},{"id":"51123","messageId":"20070820202708.GH8542@efreet.light.src","threadId":"9593","inReplyTo":"20070820201042.GA9942@glandium.org","subject":"Re: confused about preserved permissions","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-08-20T20:27:08Z","receivedAt":"2007-08-20T20:27:08Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Aug 20, 2007 at 22:10:42 +0200, Mike Hommey wrote:\n> On Mon, Aug 20, 2007 at 10:07:19PM +0200, Alex Riesen wrote:\n> > Mike Hommey, Mon, Aug 20, 2007 21:50:37 +0200:\n> > > On Mon, Aug 20, 2007 at 09:43:28PM +0200, Jan Hudec wrote:\n> > > > Git does not have tracking of file's history either.\n> > > \n> > > Well, it has ways to track file's history, with blame and log, for\n> > > example. There is nothing similar for directories, though it could be\n> > > possible to do.\n> > \n> > It would be not exactly \"tracking\". You can present the history of\n> > changes which involved the said directory.\n> > \n> > And you could do it from day one: git log -- sub/dir\n> \n> It could be possible to really do tracking, too, like it is possible for\n> files (including renames, moves, etc.)\n\nIt depends on what you imagine under tracking, but git does not track files\nin a sense of knowing about renames, moves etc. Git can't tell you -- and by\ndesign never will -- that file foo was moved to bar in revision abcdef01. All\nit can tell you is \"looking at the trees, I would guess that file foo was\nmoved to bar in revision abcdef01\". That is not tracking in a sense keeping\ntrack of anything. It is just digging out interesting similarities between\nthe individual trees.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"51124","messageId":"853ayeos82.fsf@lola.goethe.zz","threadId":"9593","inReplyTo":"20070820184829.GA8617@glandium.org","subject":"Re: confused about preserved permissions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-20T20:39:57Z","receivedAt":"2007-08-20T20:39:57Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Mike Hommey writes:\n\n> On Mon, Aug 20, 2007 at 08:40:13PM +0200, David Kastrup wrote:\n>> Mike Hommey writes:\n>> \n>> > On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup wrote:\n>> >> > I also never understood why there were no permissions set on\n>> >> > directories in trees...\n>> >> \n>> >> Because directories are not actually tracked. They are created and\n>> >> deleted as-needed.\n>> >\n>> > I don't see why it would prevent to have a permission set to\n>> > it... the permission technically can be recorded in the parent tree,\n>> > along its sha1. Filesystems are also like this.\n>> \n>> No, they aren't. Filesystems don't create and delete directories on\n>> the fly. If we record any information about a directory, deleting it\n>> automagically would not be appropriate since we would lose information\n>> that has not been explicitly deleted.\n>\n> git doesn't magically create directories either. It actually stores\n> something about them: the hash of the tree object that represents\n> them.\n\nThe tree object is not a representation of the directory in the file\nsystem. It is a hierarchical hash in the repository, stored for\nefficiency reasons.\n\n> And it has permissions associated with these hashes.\n\nNo, with the files. Think again: the link between file system and\nrepository is the index, and the current index format has no\nrepresentation for trees or directories.\n\nSo git _can't_ store any information about a _directory_, since no\ninformation about directories passes through the index.\n\n> (...)\n>> > I think i wasn't clear enough... I just wondered why the format for tree\n>> > entries is something like (if you'd write it in perl):\n>> > sprintf \"%06o %s\\0%s\", $mode, $file, pack(\"H[40]\", $sha1)\n>> \n>> Now I am sure I don't get your point.\n>\n> See what a raw tree object looks like:\n> git-cat-file tree 708453d64796eb617cb8a1602959e00356693315\n\nWell, a tree is a container for files (which in turn consist of their\npermissions, file names, and blobs).\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51126","messageId":"85y7g6ndj9.fsf@lola.goethe.zz","threadId":"9593","inReplyTo":"20070820201042.GA9942@glandium.org","subject":"Re: confused about preserved permissions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-20T20:42:34Z","receivedAt":"2007-08-20T20:42:34Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Mike Hommey writes:\n\n> On Mon, Aug 20, 2007 at 10:07:19PM +0200, Alex Riesen wrote:\n>> Mike Hommey, Mon, Aug 20, 2007 21:50:37 +0200:\n>> > On Mon, Aug 20, 2007 at 09:43:28PM +0200, Jan Hudec wrote:\n>> > > Git does not have tracking of file's history either.\n>> > \n>> > Well, it has ways to track file's history, with blame and log, for\n>> > example. There is nothing similar for directories, though it could be\n>> > possible to do.\n>> \n>> It would be not exactly \"tracking\". You can present the history of\n>> changes which involved the said directory.\n>> \n>> And you could do it from day one: git log -- sub/dir\n>\n> It could be possible to really do tracking, too, like it is possible for\n> files (including renames, moves, etc.)\n\nYou are confused. Git does not track renames or moves for files,\neither. It just records snapshots. It reverse engineers renames,\nmoves, copying when cranking out diffs and logs and blames.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51128","messageId":"20070820204459.GA10173@glandium.org","threadId":"9593","inReplyTo":"85y7g6ndj9.fsf@lola.goethe.zz","subject":"Re: confused about preserved permissions","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-20T20:44:59Z","receivedAt":"2007-08-20T20:44:59Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Aug 20, 2007 at 10:42:34PM +0200, David Kastrup wrote:\n> Mike Hommey writes:\n> \n> > On Mon, Aug 20, 2007 at 10:07:19PM +0200, Alex Riesen wrote:\n> >> Mike Hommey, Mon, Aug 20, 2007 21:50:37 +0200:\n> >> > On Mon, Aug 20, 2007 at 09:43:28PM +0200, Jan Hudec wrote:\n> >> > > Git does not have tracking of file's history either.\n> >> > \n> >> > Well, it has ways to track file's history, with blame and log, for\n> >> > example. There is nothing similar for directories, though it could be\n> >> > possible to do.\n> >> \n> >> It would be not exactly \"tracking\". You can present the history of\n> >> changes which involved the said directory.\n> >> \n> >> And you could do it from day one: git log -- sub/dir\n> >\n> > It could be possible to really do tracking, too, like it is possible for\n> > files (including renames, moves, etc.)\n> \n> You are confused. Git does not track renames or moves for files,\n> either. It just records snapshots. It reverse engineers renames,\n> moves, copying when cranking out diffs and logs and blames.\n\nYes, I know. And that could be done for directories, too.\n\nMike\n"},{"id":"51131","messageId":"20070820205042.GB10173@glandium.org","threadId":"9593","inReplyTo":"853ayeos82.fsf@lola.goethe.zz","subject":"Re: confused about preserved permissions","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-20T20:50:42Z","receivedAt":"2007-08-20T20:50:42Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Aug 20, 2007 at 10:39:57PM +0200, David Kastrup wrote:\n> > And it has permissions associated with these hashes.\n> \n> No, with the files. Think again: the link between file system and\n> repository is the index, and the current index format has no\n> representation for trees or directories.\n> \n> So git _can't_ store any information about a _directory_, since no\n> information about directories passes through the index.\n\nIf, as Jan suggested in a previous message, you introduce directories in\nthe index, I still don't see why you would need two entries in the tree\nobject...\n\n> > (...)\n> >> > I think i wasn't clear enough... I just wondered why the format for tree\n> >> > entries is something like (if you'd write it in perl):\n> >> > sprintf \"%06o %s\\0%s\", $mode, $file, pack(\"H[40]\", $sha1)\n> >> \n> >> Now I am sure I don't get your point.\n> >\n> > See what a raw tree object looks like:\n> > git-cat-file tree 708453d64796eb617cb8a1602959e00356693315\n> \n> Well, a tree is a container for files (which in turn consist of their\n> permissions, file names, and blobs).\n\nThe question here was why the permissions are encoded with \"%06o\" while\nthe hash is packed. Anyways, it's just a boring detail.\n\nMike\n"},{"id":"51132","messageId":"85k5rpor4n.fsf@lola.goethe.zz","threadId":"9593","inReplyTo":"20070820205042.GB10173@glandium.org","subject":"Re: confused about preserved permissions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-20T21:03:36Z","receivedAt":"2007-08-20T21:03:36Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Mike Hommey writes:\n\n> On Mon, Aug 20, 2007 at 10:39:57PM +0200, David Kastrup wrote:\n>> > And it has permissions associated with these hashes.\n>> \n>> No, with the files. Think again: the link between file system and\n>> repository is the index, and the current index format has no\n>> representation for trees or directories.\n>> \n>> So git _can't_ store any information about a _directory_, since no\n>> information about directories passes through the index.\n>\n> If, as Jan suggested in a previous message, you introduce\n> directories in the index, I still don't see why you would need two\n> entries in the tree object...\n\nAs I already said: you don't. It may just be _convenient_ in the\n_index_ for doing single pass merge collision detection (when a\ndirectory is replaced by a file or vice versa). But there would be no\nadditional information stored in the index, and it definitely would\nnot be worth to do double entries in the repository: the repository is\nalready capable of representing all the desired information and it\nwould be wasteful to introduce any complications there when the\ncurrent format already is fine.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51142","messageId":"20070821013541.GC27913@spearce.org","threadId":"9593","inReplyTo":"20070820205042.GB10173@glandium.org","subject":"Re: confused about preserved permissions","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-21T01:35:41Z","receivedAt":"2007-08-21T01:35:41Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Mike Hommey wrote:\n> > >> > sprintf \"%06o %s\\0%s\", $mode, $file, pack(\"H[40]\", $sha1)\n> \n> The question here was why the permissions are encoded with \"%06o\" while\n> the hash is packed. Anyways, it's just a boring detail.\n\nBecause text format is simple and pretty much everyone understands\nit, especially when you are talking about UNIX mode/permission\nbits in octal, the name is \"text\", and then oh, wait, those 40\nbytes of hex is a lot of data - we'll just make that 20 bytes of\nbinary instead. :-)\n\nOK, I don't know if that's really true. Probably only Linus can\nspeak to why the tree format is what it is. Its just how I have\nrationalized it myself.\n\nPack v4 changes the storage of the mode to be in binary, at least\nwithin the packfile, but it does still have to convert it back to the\n\"%06o\" format when computing the SHA-1 of a tree object. Believe it\nor not, pack v4 is being worked on again... so maybe in a future\nversion of Git the tree modes will take up a tiny bit less space.\n\nI haven't specifically looked at this, but I would also suspect that\nwithin any given tree's zlib dictionary the mode string portion is\ngiven a reasonably short bit sequence. So its doubtful that the\nmode takes up 6 bytes when compressed by zlib, its probably more\nlikely around 1 byte. Pack v4's big win here isn't due to the mode,\nits due to the filenames being compressed better across trees.\n\n-- \nShawn.\n"},{"id":"51143","messageId":"7vejhxproc.fsf@gitster.siamese.dyndns.org","threadId":"9593","inReplyTo":"20070821013541.GC27913@spearce.org","subject":"Re: confused about preserved permissions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-21T02:06:27Z","receivedAt":"2007-08-21T02:06:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Mike Hommey wrote:\n>> > >> > sprintf \"%06o %s\\0%s\", $mode, $file, pack(\"H[40]\", $sha1)\n>> \n>> The question here was why the permissions are encoded with \"%06o\" while\n>> the hash is packed. Anyways, it's just a boring detail.\n>\n> Because text format is simple and pretty much everyone understands\n> it, especially when you are talking about UNIX mode/permission\n> bits in octal, the name is \"text\", and then oh, wait, those 40\n> bytes of hex is a lot of data - we'll just make that 20 bytes of\n> binary instead. :-)\n\nThat is almost true, but there is one factual error I need to\ncorrect.\n\nIn-tree representation of the mode is not actually \"%06o\" but\njust \"%o\". In very early days of git, we used to have extra\nleading \"0\" in trees (e.g. \"040000\"), but that is something\nmodern fsck even warns about. IOW, it is not the norm.\n\nIt is represented as text because we _can_ add any number of\nbits to the data later if we wanted to. Basic tree objects that\ncontain only the kind of data we traditionally used will\ncontinue to work, while trees that contain (yet to be invented)\nnew types that are represented with longer mode bits may of\ncourse not be read by older tools.\n\nOn the other hand, by definition, SHA-1 is 20-bytes. If we\nwanted to be able to replace hash function, we _could_ have done\nhashtype + length + data format (and length is represented with\neither text or \"7-bit-per-byte plus stop bit\" format as in the\npack format), but there was no reason to.\n\nThe same logic applies to the loose object header -- length is\nnot \"network byte order 4-byte integer\" (or 8-byte), but just a\ntextual representation of an unsigned integer of unspecified\nlength. The current code happen to use \"%lu\" with ulong only\nbecause that is the largest integral type that can be used\nportably and is not cumbersome to use. On future architectures\nwith larger word size, we do not have to update the data\nstructure definition nor even the code to read and write loose\nobjects. Using a blob that is longer than 2^64 bytes may or may\nnot be possible depending on how long your ulong is, of course.\n"},{"id":"51148","messageId":"20070821053451.GA11153@glandium.org","threadId":"9593","inReplyTo":"7vejhxproc.fsf@gitster.siamese.dyndns.org","subject":"Re: confused about preserved permissions","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-21T05:34:51Z","receivedAt":"2007-08-21T05:34:51Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Aug 20, 2007 at 07:06:27PM -0700, Junio C Hamano wrote:\n> That is almost true, but there is one factual error I need to\n> correct.\n> \n> In-tree representation of the mode is not actually \"%06o\" but\n> just \"%o\". In very early days of git, we used to have extra\n> leading \"0\" in trees (e.g. \"040000\"), but that is something\n> modern fsck even warns about. IOW, it is not the norm.\n> \n> It is represented as text because we _can_ add any number of\n> bits to the data later if we wanted to. Basic tree objects that\n> contain only the kind of data we traditionally used will\n> continue to work, while trees that contain (yet to be invented)\n> new types that are represented with longer mode bits may of\n> course not be read by older tools.\n(...)\n\nThat makes sense. (BTW, I must have misremembered the %06o thing,\nbecause my script to hash random trees does use %o).\n\nAnyways, that still doesn't say why all these permission bits are kept\nwhile only the executable bit matters, though it must be related to\nbackwards compatibility of hashes.\n\nI'd also like to head about why git-archive doesn't set permissions like\nthe manpage says (see my first post in the thread)\n\nMike\n"},{"id":"51149","messageId":"856439o23l.fsf@lola.goethe.zz","threadId":"9593","inReplyTo":"20070821053451.GA11153@glandium.org","subject":"Re: confused about preserved permissions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-21T06:04:14Z","receivedAt":"2007-08-21T06:04:14Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Mike Hommey writes:\n\n> Anyways, that still doesn't say why all these permission bits are\n> kept while only the executable bit matters, though it must be\n> related to backwards compatibility of hashes.\n\nIt is not much that will in practice be retained. Keeping the whole\nkaboodle (including uid and gid) makes git suitable for archival\npurposes on Posixy platforms. The current code offers just a single\npolicy (suitable for distributed development) with regard to what it\nmaintains and stores (well, actually two: you can tell it to ignore\nthe execute bit from the file system), but it would be reasonably\nstraightforward to extend this with further policies.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51190","messageId":"46CB285D.3010909@lsrfire.ath.cx","threadId":"9593","inReplyTo":"20070820174142.GA7943@glandium.org","subject":"Re: confused about preserved permissions","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-08-21T18:01:01Z","receivedAt":"2007-08-21T18:01:01Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Mike Hommey schrieb:\n> On Mon, Aug 20, 2007 at 06:44:11PM +0200, martin f krafft wrote:\n>> Why does git bother saving a mode when later it never seems to use\n>> it again?\n> \n> Same applies to git-archive, which generates files with mode 666 and\n> directories with 777, while it could follow the modes in the\n> repository... or at least, that's what the manpage claims, but facts\n> seem to be quite different...\n> \n> mh@namakemono:~/git/git$ git-archive --format=tar HEAD | tar -tvf -\n> -rw-rw-r-- root/root 2365 2007-08-19 20:45 .gitignore\n> -rw-rw-r-- root/root 1973 2007-08-19 20:45 .mailmap\n> -rw-rw-r-- root/root 18787 2007-08-19 20:45 COPYING\n> drwxrwxr-x root/root 0 2007-08-19 20:45 Documentation/\n\n> mh@namakemono:~/git/git$ umask\n> 0022\n> \n> And no value is set for umask in git config...\n\nIn that case the default value for tar.umask applies, which is 002. The\nmanpage needs an update.. Thanks for spotting this.\n\nYou can set it to 022 explicitly or to \"user\" to restrict permissions:\n\n $ git config tar.umask 022\t\t# -rw-r--r--\n $ git config tar.umask user\t\t# your Unix umask applies\n\nOriginally file permissions were simply copied into the archive, but\nthis was inconvenient for users that needed more permission bits set,\ne.g. to share an extracted archive with with others by default.\n\nAlso please note that tar applies your umask when extracting files\n(exception: GNU tar doesn't do that by default if run as root), so the\npermissions of extracted files may look different from the output of\n\"tar -t\".\n\nRené\n"},{"id":"51189","messageId":"46CB286C.8000403@lsrfire.ath.cx","threadId":"9593","inReplyTo":"20070820174142.GA7943@glandium.org","subject":"[PATCH] Documentation: update tar.umask default","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-08-21T18:01:16Z","receivedAt":"2007-08-21T18:01:16Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"As noted by Mike Hommey, the documentation for the config setting tar.umask\nis not up-to-date. Commit f08b3b0e2e9ad87767d80ff03b013c686e08ba4b changed\nthe default from 0 to 2; this patch finally documents it.\n\nSigned-off-by: Rene Scharfe \n---\ndiff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt\nindex 4da07c1..9984a11 100644\n--- a/Documentation/git-archive.txt\n+++ b/Documentation/git-archive.txt\n@@ -80,8 +80,8 @@ in the repository configuration as follows :\n umask = 002\t;# group friendly\n \n The special umask value \"user\" indicates that the user's current umask\n-will be used instead. The default value remains 0, which means world\n-readable/writable files and directories.\n+will be used instead. The default is 002, which allows reading for all\n+and writing for both owner and group.\n \n EXAMPLES\n --------\n"},{"id":"51202","messageId":"20070821211526.GA12483@glandium.org","threadId":"9593","inReplyTo":"46CB286C.8000403@lsrfire.ath.cx","subject":"Re: [PATCH] Documentation: update tar.umask default","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-21T21:15:26Z","receivedAt":"2007-08-21T21:15:26Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Aug 21, 2007 at 08:01:16PM +0200, René Scharfe wrote:\n> As noted by Mike Hommey, the documentation for the config setting tar.umask\n> is not up-to-date. Commit f08b3b0e2e9ad87767d80ff03b013c686e08ba4b changed\n> the default from 0 to 2; this patch finally documents it.\n> \n> Signed-off-by: Rene Scharfe \n> ---\n> diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt\n> index 4da07c1..9984a11 100644\n> --- a/Documentation/git-archive.txt\n> +++ b/Documentation/git-archive.txt\n> @@ -80,8 +80,8 @@ in the repository configuration as follows :\n> umask = 002\t;# group friendly\n> \n> The special umask value \"user\" indicates that the user's current umask\n> -will be used instead. The default value remains 0, which means world\n> -readable/writable files and directories.\n> +will be used instead. The default is 002, which allows reading for all\n> +and writing for both owner and group.\n\nActually, I'd say it's not enough ; users may be confused by the\nsentence just above:\n\nBy default, file and directories modes are set to 0666 or 0777 in tar\narchives.\n\nWhich is true, but if you are not very familiar with umask, you won't\nactually gather from the rest that the modes are not going to be that by\ndefault.\n\nMike\n"},{"id":"51243","messageId":"6031FB22-648E-47DE-92EE-2E7255322C27@lrde.epita.fr","threadId":"9593","inReplyTo":"20070820164411.GA15637@piper.oerlikon.madduck.net","subject":"Re: confused about preserved permissions","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-08-22T12:18:19Z","receivedAt":"2007-08-22T12:18:19Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Aug 20, 2007, at 6:44 PM, martin f krafft wrote:\n\n> Hello,\n>\n> I am a bit confused about how git stores and restores permissions.\n[...]\n> And is there a way to tell git not to mess with the permissions in\n> the worktree when switching branches? I am not sure what's causing\n> it since the inode of files does not seem to change, so git\n> apparently explicitly fchmod()'s files.\n>\n> I'd be grateful for any documentation to read in addition to the\n> code. I saw core.filemode, but that's only about the x bit, it\n> seems.\n>\n> Thanks,\n\nHi,\nthis thread drifted away and although the discussion is interesting, \nthe original question hasn't been answered so far and I am in a \nsituation where I'd like to know the answer (because my working tree \nneeds to be group-readable for a given project and my umask 066 keeps \nannoying me although I don't want to change it).\n\nSomeone on IRC pointed me to http://git.or.cz/gitwiki/ \nContentLimitations which says:\n\n\"By design, git cannot track other aspects of the filesystem, including:\n * File modes (except for the \"executable\" bit, and being symbolic \nlink)\"\n\nThat's weird since the file mode is saved in the tree, isn't there a \nway to ask Git to restore this file mode?\n\nCheers,\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"51247","messageId":"46CC3194.764A29D4@eudaptics.com","threadId":"9593","inReplyTo":"6031FB22-648E-47DE-92EE-2E7255322C27@lrde.epita.fr","subject":"Re: confused about preserved permissions","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-08-22T12:52:36Z","receivedAt":"2007-08-22T12:52:36Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Benoit SIGOURE wrote:\n> this thread drifted away and although the discussion is interesting,\n> the original question hasn't been answered so far and I am in a\n> situation where I'd like to know the answer (because my working tree\n> needs to be group-readable for a given project and my umask 066 keeps\n> annoying me although I don't want to change it).\n> \n> Someone on IRC pointed me to http://git.or.cz/gitwiki/\n> ContentLimitations which says:\n> \n> \"By design, git cannot track other aspects of the filesystem, including:\n> * File modes (except for the \"executable\" bit, and being symbolic\n> link)\"\n> \n> That's weird since the file mode is saved in the tree, isn't there a\n> way to ask Git to restore this file mode?\n\nAt this time, there is not. git tracks only the executable bit. Even\nthough it stores (and reports) the complete mode, it only ever stores\none of these mode values: 100644, 100755, 120000. Yes, that's an\nenormous waste of bits, but that's how it is.\n\n-- Hannes\n"},{"id":"51291","messageId":"46CCA496.2020101@lsrfire.ath.cx","threadId":"9593","inReplyTo":"20070821211526.GA12483@glandium.org","subject":"Re: [PATCH] Documentation: update tar.umask default","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-08-22T21:03:18Z","receivedAt":"2007-08-22T21:03:18Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Mike Hommey schrieb:\n> Actually, I'd say it's not enough ; users may be confused by the\n> sentence just above:\n> \n> By default, file and directories modes are set to 0666 or 0777 in tar\n> archives.\n> \n> Which is true, but if you are not very familiar with umask, you won't\n> actually gather from the rest that the modes are not going to be that by\n> default.\n\nHmm. And I forgot to update two other places. How about this? Too short?\n\n Documentation/config.txt | 14 +++++---------\n Documentation/git-archive.txt | 15 ++++++---------\n Documentation/git-tar-tree.txt | 15 ++++++---------\n 3 files changed, 17 insertions(+), 27 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 46f40ad..462595c 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -675,15 +675,11 @@ showbranch.default::\n \tSee gitlink:git-show-branch[1].\n \n tar.umask::\n-\tBy default, gitlink:git-tar-tree[1] sets file and directories modes\n-\tto 0666 or 0777. While this is both useful and acceptable for projects\n-\tsuch as the Linux Kernel, it might be excessive for other projects.\n-\tWith this variable, it becomes possible to tell\n-\tgitlink:git-tar-tree[1] to apply a specific umask to the modes above.\n-\tThe special value \"user\" indicates that the user's current umask will\n-\tbe used. This should be enough for most projects, as it will lead to\n-\tthe same permissions as gitlink:git-checkout[1] would use. The default\n-\tvalue remains 0, which means world read-write.\n+\tThis variable can be used to restrict the permission bits of\n+\ttar archive entries. The default is 0002, which turns off the\n+\tworld write bit. The special value \"user\" indicates that the\n+\tarchiving user's umask will be used instead. See umask(2) and\n+\tgitlink:git-archive[1].\n \n user.email::\n \tYour email address to be recorded in any newly created commits.\ndiff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt\nindex 4da07c1..f2080eb 100644\n--- a/Documentation/git-archive.txt\n+++ b/Documentation/git-archive.txt\n@@ -72,16 +72,13 @@ zip\n \n CONFIGURATION\n -------------\n-By default, file and directories modes are set to 0666 or 0777 in tar\n-archives. It is possible to change this by setting the \"umask\" variable\n-in the repository configuration as follows :\n \n-[tar]\n- umask = 002\t;# group friendly\n-\n-The special umask value \"user\" indicates that the user's current umask\n-will be used instead. The default value remains 0, which means world\n-readable/writable files and directories.\n+tar.umask::\n+\tThis variable can be used to restrict the permission bits of\n+\ttar archive entries. The default is 0002, which turns off the\n+\tworld write bit. The special value \"user\" indicates that the\n+\tarchiving user's umask will be used instead. See umask(2) for\n+\tdetails.\n \n EXAMPLES\n --------\ndiff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt\nindex 2d01d96..434607b 100644\n--- a/Documentation/git-tar-tree.txt\n+++ b/Documentation/git-tar-tree.txt\n@@ -42,16 +42,13 @@ OPTIONS\n \n CONFIGURATION\n -------------\n-By default, file and directories modes are set to 0666 or 0777. It is\n-possible to change this by setting the \"umask\" variable in the\n-repository configuration as follows :\n \n-[tar]\n- umask = 002\t;# group friendly\n-\n-The special umask value \"user\" indicates that the user's current umask\n-will be used instead. The default value is 002, which means group\n-readable/writable files and directories.\n+tar.umask::\n+\tThis variable can be used to restrict the permission bits of\n+\ttar archive entries. The default is 0002, which turns off the\n+\tworld write bit. The special value \"user\" indicates that the\n+\tarchiving user's umask will be used instead. See umask(2) for\n+\tdetails.\n \n EXAMPLES\n --------\n"},{"id":"51300","messageId":"7v8x83i5ma.fsf@gitster.siamese.dyndns.org","threadId":"9593","inReplyTo":"6031FB22-648E-47DE-92EE-2E7255322C27@lrde.epita.fr","subject":"Re: confused about preserved permissions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-22T22:09:17Z","receivedAt":"2007-08-22T22:09:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Benoit SIGOURE writes:\n\n> Someone on IRC pointed me to http://git.or.cz/gitwiki/\n> ContentLimitations which says:\n>\n> \"By design, git cannot track other aspects of the filesystem, including:\n> * File modes (except for the \"executable\" bit, and being symbolic\n> link)\"\n>\n> That's weird since the file mode is saved in the tree, isn't there a\n> way to ask Git to restore this file mode?\n\nThe wording you quoted is wrong. By design, we \"chose not to\"\ntrack other aspects, even though the underlying data structure\nhas enough space to use other bit patterns.\n\nWe deliberately chose not to use that space, and this default is\nvery unlikely to change.\n\nIn very early days of git, we allowed the work tree modes 0644\nvs 0664 propagated back to the index modes and regular file\nmodes recorded in the tree entries. This caused unnecessary\npain for poeple merging real projects for no real gain\nwhatsoever, and the behaviour was fixed to minimally track,\nhence we do not track anything but executable bits.\n\nI do not oppose to a new per-project configuration option to\nmake use of the existing space to record differences vs 0644 vs\n0664 vs 0600. However, I have already seen the downsides, so:\n\n (1) I am not interested in implementing that myself;\n\n (2) the places that canonicalize the mode bits obtained from\n the filesystem to 0644 is fairly centralized so it would\n not be too hard to implement (and that is one good reason\n why I do _not_ have to be the person to do so);\n\n (3) however, (2) means that everybody calls that\n canonicalization logic, and the unintended side effects\n need to be audited for codepaths of all the callers, which\n means a large test suite is probably needed; and\n\n (4) to me, reviewing such a patch will be much lower priority\n than other patches for the above reasons.\n"},{"id":"51328","messageId":"20070823060052.GA25153@piper.oerlikon.madduck.net","threadId":"9593","inReplyTo":"7v8x83i5ma.fsf@gitster.siamese.dyndns.org","subject":"Re: confused about preserved permissions","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-23T06:00:52Z","receivedAt":"2007-08-23T06:00:52Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Junio C Hamano [2007.08.23.0009 +0200]:\n> We deliberately chose not to use that space, and this default is\n> very unlikely to change.\n\nThe downsides included change in SHA hash on mode change, as far as\nI can remember. Anything else?\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"wickedness is a myth\n invented by good people\n to account for the curious attraction of others.\"\n -- oscar wilde\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"51330","messageId":"85mywiixtp.fsf@lola.goethe.zz","threadId":"9593","inReplyTo":"20070823060052.GA25153@piper.oerlikon.madduck.net","subject":"Re: confused about preserved permissions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-23T06:12:18Z","receivedAt":"2007-08-23T06:12:18Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"martin f krafft writes:\n\n> also sprach Junio C Hamano [2007.08.23.0009 +0200]:\n>> We deliberately chose not to use that space, and this default is\n>> very unlikely to change.\n>\n> The downsides included change in SHA hash on mode change, as far as\n> I can remember. Anything else?\n\nThe modes are recorded in patches and push/pull, so if you have\nseveral people working with different permissions/umasks, you get\nwagonloads of unnecessary patches and get your local permissions\nmessed up by other contributors.\n\nFor colloborative work, you _really_ don't want to have _personal_\npreferences distributed.\n\nAny patch offering to optionally track permissions must make very sure\nthat it retains the possibility to have permissions in the directory\npoliced to the values that are actually a property of the source files\nrather than the personal work environment.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51331","messageId":"20070823062342.GA29172@piper.oerlikon.madduck.net","threadId":"9593","inReplyTo":"85mywiixtp.fsf@lola.goethe.zz","subject":"Re: confused about preserved permissions","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-23T06:23:42Z","receivedAt":"2007-08-23T06:23:42Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach David Kastrup [2007.08.23.0812 +0200]:\n> The modes are recorded in patches and push/pull, so if you have\n> several people working with different permissions/umasks, you get\n> wagonloads of unnecessary patches and get your local permissions\n> messed up by other contributors.\n> \n> For colloborative work, you _really_ don't want to have _personal_\n> preferences distributed.\n\nHow about a patch that\n\n (a) ensures that modes of existing files are preserved\n across checkouts and merges?\n (b) for files it creates (e.g. checkout of a branch introducing\n a file), it consults the default for this file tracked in the\n archive and uses that.\n (c) in order to change the mode recorded for a file, a user has to\n tell git-add to specifically record the mode change in the\n index.\n\nThere should be a tri-state policy: mode-from-archive vs. umask, and\numask could be according to core.umask or if that's set to user,\nthen the user's umask.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"the only difference between shakespeare and you\n was the size of his idiom list -- not the size of his vocabulary.\"\n -- alan perlis\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"51334","messageId":"7vodgyvikp.fsf@gitster.siamese.dyndns.org","threadId":"9593","inReplyTo":"20070823060052.GA25153@piper.oerlikon.madduck.net","subject":"Re: confused about preserved permissions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-23T07:03:18Z","receivedAt":"2007-08-23T07:03:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"martin f krafft writes:\n\n> also sprach Junio C Hamano [2007.08.23.0009 +0200]:\n>> We deliberately chose not to use that space, and this default is\n>> very unlikely to change.\n>\n> The downsides included change in SHA hash on mode change, as far as\n> I can remember. Anything else?\n\nMore serious practical problem was that sane developers tend to\nhave either 022 or 002 umask. You may check out my project\n(whose regular files are either 0664 or 0775, according to my\numask settings), but the checkout honors your umask and you\nwould get 0644 or 0755 on your copies, and you would check in\nwith differemtn modes. The merge I would do later with you\nwould get needless conflicts on modes.\n\nWhat makes the mode conflict \"needless\" is that we are primarily\ntalking about source code control, by the way. It is very\nreasonable if you want to retarget git, probably borrowing most\nof its infrastructure, to build a backup system to keep track of\nfiles in /etc hierarchy. It would be crucial for _your_ system\nto keep track of owner/group and mode bits. If the modes or\nownership conflict during a merge, that is _not_ needless\nconflict at all --- the user needs to decide if /etc/shadow\nshould or should not be world readable, and send a nasty message\nto whoever asked you to pull such a change to make the file\nworld readable after you detect such a mistake while you are\nmerging. It becomes essential to your \"backup\" system.\n\nBut in the context of git project, and source code management,\nwhich is its primary application, it is not worth to keep track\nof such mode differences that come from umask differences of\ncontributors. You could add such a full-mode-bits and ownership\nsupport to git, but that would stay secondary at best. It is\nentirely possible that the code to support such an extension\nwould be too intrusive to clutter git codebase, at which point\nthe \"backup\" application may have to become a fork of git, not\npart of it.\n"},{"id":"51337","messageId":"B38B8F2F-92B0-48F4-9093-54724FA862C2@lrde.epita.fr","threadId":"9593","inReplyTo":"85mywiixtp.fsf@lola.goethe.zz","subject":"Re: confused about preserved permissions","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-08-23T07:48:23Z","receivedAt":"2007-08-23T07:48:23Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"\nOn Aug 23, 2007, at 8:12 AM, David Kastrup wrote:\n\n> martin f krafft writes:\n>\n>> also sprach Junio C Hamano [2007.08.23.0009 \n>> +0200]:\n>>> We deliberately chose not to use that space, and this default is\n>>> very unlikely to change.\n>>\n>> The downsides included change in SHA hash on mode change, as far as\n>> I can remember. Anything else?\n>\n> The modes are recorded in patches and push/pull, so if you have\n> several people working with different permissions/umasks, you get\n> wagonloads of unnecessary patches and get your local permissions\n> messed up by other contributors.\n>\n> For colloborative work, you _really_ don't want to have _personal_\n> preferences distributed.\n>\n> Any patch offering to optionally track permissions must make very sure\n> that it retains the possibility to have permissions in the directory\n> policed to the values that are actually a property of the source files\n> rather than the personal work environment.\n>\n\nHmm yes, that's right.\n\nLet's look at the problem from another point of view then: I want my \n*working tree* to be group readable even though my umask is 066. \nWould it be possible to add a local config option in the .git repo to \ntell git that it should create new file this way (exactly like \ncore.sharedRepository but core.sharedWorkingCopy or whatever).\n\nWDYT?\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"51340","messageId":"7vfy2avg2b.fsf@gitster.siamese.dyndns.org","threadId":"9593","inReplyTo":"B38B8F2F-92B0-48F4-9093-54724FA862C2@lrde.epita.fr","subject":"Re: confused about preserved permissions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-23T07:57:32Z","receivedAt":"2007-08-23T07:57:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Benoit SIGOURE writes:\n\n> Let's look at the problem from another point of view then: I want my\n> *working tree* to be group readable even though my umask is 066.\n\nI have to wonder if there is any sane development tool that\nsupports that kind of thing. E.g. vi, emacs, gcc,...? If you\nallowed a tool to do that, what's the point of having a umask?\n"},{"id":"51341","messageId":"86fy2abrm5.fsf@lola.quinscape.zz","threadId":"9593","inReplyTo":"7vfy2avg2b.fsf@gitster.siamese.dyndns.org","subject":"Re: confused about preserved permissions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-23T08:08:18Z","receivedAt":"2007-08-23T08:08:18Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Benoit SIGOURE writes:\n>\n>> Let's look at the problem from another point of view then: I want my\n>> *working tree* to be group readable even though my umask is 066.\n>\n> I have to wonder if there is any sane development tool that\n> supports that kind of thing. E.g. vi, emacs, gcc,...? If you\n> allowed a tool to do that, what's the point of having a umask?\n\nHm? Are we talking about the same Emacs here? The thing that has a\ndirectory editor built into it with which one can do chmod and so on?\n\nHere are a few functions:\n\n executable-make-buffer-file-executable-if-script-p is an autoloaded Lisp function in `executable'.\n (executable-make-buffer-file-executable-if-script-p)\n\n Make file executable according to umask if not already executable.\n If file already has any execute bits set at all, do not change existing\n file modes.\n\n\n----------------\ndired-do-chmod\n Command: Change the mode of the marked (or next ARG) files.\nThis calls chmod, thus symbolic modes like `g+w' are allowed.\n\n(fn &optional ARG)\n\n----------------\nexecutable-set-magic\n Command: Set this buffer's interpreter to INTERPRETER with optional ARGUMENT.\nThe variables `executable-magicless-file-regexp', `executable-prefix',\n`executable-insert', `executable-query' and `executable-chmod' control\nwhen and how magic numbers are inserted or replaced and scripts made\nexecutable.\n\n(fn INTERPRETER &optional ARGUMENT NO-QUERY-FLAG INSERT-FLAG)\n\n\n\nHowever, Emacs does not provide a hook into the system call as far as\nI can see: it calls chmod explicitly.\n\n\n-- \nDavid Kastrup\n"},{"id":"52374","messageId":"20070903185916.GA3786@efreet.light.src","threadId":"9593","inReplyTo":"B38B8F2F-92B0-48F4-9093-54724FA862C2@lrde.epita.fr","subject":"Re: confused about preserved permissions","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-03T18:59:16Z","receivedAt":"2007-09-03T18:59:16Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, Aug 23, 2007 at 09:48:23 +0200, Benoit SIGOURE wrote:\n> Hmm yes, that's right.\n>\n> Let's look at the problem from another point of view then: I want my \n> *working tree* to be group readable even though my umask is 066. Would it \n> be possible to add a local config option in the .git repo to tell git that \n> it should create new file this way (exactly like core.sharedRepository but \n> core.sharedWorkingCopy or whatever).\n>\n> WDYT?\n\nYou need to change umask not just for git, but for your editor and compiler\nwhen you are working in the shared work tree as well, no? So what about\nteaching your *shell* to change it as appropriate?\n\nIn zsh if you define a function chpwd, it will be called whenever you change\ncurrent working directory. If you define it as:\n\nchpwd() {\n # The / at the end is to make foo/* match path foo\n case `pwd`/ in\n\t/path/to/your/worktree/*) umask 002;;\n\t*) umask 066;;\n esac\n}\n\nwould make any command (ie. git, editor and compiler/make/...) ran from the\nshared worktree run with umask 002 (or whatever depending on permissions you\nwant there) and anything ran from anywhere else use your normal umask 066.\n\nI don't use bash, but I am almost sure you can get a suitable hook there as\nwell. If nothing else I recall there is a way to run a function from prompt\nexpansion, which would do the trick.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}