Re: metastore

From: martin f krafft <madduck@madduck.net>
Date: Sep 17, 2007, 13:30 UTC
Message-ID: <20070917133000.GD16773@lapse.madduck.net>
In-Reply-To: <Pine.LNX.4.64.0709161507130.24221@asgard.lang.hm>

also sprach david@lang.hm <david@lang.hm> [2007.09.17.0037 +0200]:

Show 20 quoted lines

>> 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. ..."

Show 7 quoted lines

>> (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