also sprach david@xxxxxxx <david@xxxxxxx> [2007.09.17.0037 +0200]: >> While we're at it, you probably don't even want to write the >> permission file to the live filesystem. It's just one more thing >> that could leak information, and changes to the permissions of >> files that you record by committing the live filesystem would >> presumably be done by changing the permissions of files in the >> filesystem, not by changing the text file. > > the permissions and ACL's can be queried directly from the > filesystem, so I don't see any security problems with writing the > permission file to the filesystem. > > changing the permissions would be done by changing the files > themselves (when you are running as root on a filesystem that > supports the changes, otherwise it would need to fall back to > writing the file and getting the changes there, but that should be > able to be a local config option) > > I don't like the idea of having a file that doesn't appear on the > local filesystem at any point, it just makes troubleshooting too > hard. Reading over your thoughts, I get this uneasy feeling about such a permissions file, because it stores redundant information, and redundant information has a tendency to get out of sync. If we cannot attach attributes to objects in the git database, then I understand the need for such a metastore. But I don't think it should be checked out and visible, or maybe we should think of it not in terms of a file anyway, but a metastore. Or how do you want to resolve the situation when a user might edit the file, changing a mode from 644 to 640, while in the filesystem, it was changed by other means to 600. .gitattributes is a different story since it stores git-specificy attributes, which are present nowhere else in the checkout. I still maintain it would be best if git allowed extra data to be attached to object nodes. When you start thinking about cherry-picking or even simple merges, I think that makes most sense. And we don't need conflict markers, we could employ an iterative merge process as e.g. git-rebase uses: "a conflict has been found in the file mode of ... ... 2750 vs. 2755 ... please set the file mode as it should be and do git-merge --continue. Or git-merge --abort. ..." >> (Of course, you could check out the same commits as ordinary source, with >> developer-owned 644 files and a 644 "permissions" file, and there you'd >> have the permissions file appear in the work tree, and you could edit it >> and check it in in a totally mundane way.) > > right, and the same thing if the filesystem doesn't support something in the > permission file. I'd much rather see something like `git-attr chmod 644 file-in-index` to make this change, rather than a file, which introduces the potential for syntax errors. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck "to me, vi is zen. to use vi is to practice zen. every command is a koan. profound to the user, unintelligible to the uninitiated. you discover truth everytime you use it." -- reddy ät lion.austin.ibm.com spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
