Re: metastore

[martin f krafft <madduck@madduck.net>]

[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]

also sprach david@lang.hm <david@lang.hm> [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@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]