Mike Hommey <mh@xxxxxxxxxxxx> writes:
> On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup <dak@xxxxxxx> wrote:
>> > I also never understood why there were no permissions set on
>> > directories in trees...
>>
>> Because directories are not actually tracked. They are created and
>> deleted as-needed.
>
> I don't see why it would prevent to have a permission set to
> it... the permission technically can be recorded in the parent tree,
> along its sha1. Filesystems are also like this.
No, they aren't. Filesystems don't create and delete directories on
the fly. If we record any information about a directory, deleting it
automagically would not be appropriate since we would lose information
that has not been explicitly deleted.
>> Other permissions would correspond to a tracked directory. I am still
>> stuck over the representation in the index.
>>
>> One idea is to unconditionally have an entry "dirname" without
>> permissions, and optionally "dirname/" with permissions iff the
>> directory is supposed to be tracked, both to be sorted in
>> alphabetically. The idea of the first entry is being able to detect
>> merge conflicts without extra passes.
>>
>> But I have not worked on the stuff for a while.
>
> I don't see why you would need an additional entry for the directory
> permission.
One doesn't. It would be just there to facilitate single-pass
detection of merge conflicts. No non-redundant information content to
it at all, but it delivers the "we'll need a directory here"
information earlier in the sort order.
But one can probably do without that by just stashing away
non-directory entries namex* possibly colliding with a tree until the
opportunity for namex/* has passed by, and then processing them. That
makes for a cleaner index format.
There is still the question when one stores just a single entry
whether to sort this under "namex" or "namex/" and whether to also
have it appear when it corresponds to a non-tracked directory.
It does not really make sense settling on one format before one
implements the various merge/update/checkout utilities since then one
sees what is most convenient.
>> > nor why, while the sha1 for child objects are "packed", the modes
>> > aren't...
>>
>> Because a change of the mode of a file will then not cause different
>> sha1 sums at the file level.
>
> I think i wasn't clear enough... I just wondered why the format for tree
> entries is something like (if you'd write it in perl):
> sprintf "%06o %s\0%s", $mode, $file, pack("H[40]", $sha1)
Now I am sure I don't get your point.
--
David Kastrup
-
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
