Mike Hommey [off-list ref] writes:
On Mon, Aug 20, 2007 at 08:40:13PM +0200, David Kastrup [off-list ref] wrote:
quoted
Mike Hommey [off-list ref] writes:
quoted
On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup [off-list ref] wrote:
quoted
quoted
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.
git doesn't magically create directories either. It actually stores
something about them: the hash of the tree object that represents
them.
The tree object is not a representation of the directory in the file
system. It is a hierarchical hash in the repository, stored for
efficiency reasons.
And it has permissions associated with these hashes.
No, with the files. Think again: the link between file system and
repository is the index, and the current index format has no
representation for trees or directories.
So git _can't_ store any information about a _directory_, since no
information about directories passes through the index.
(...)
quoted
quoted
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.
See what a raw tree object looks like:
git-cat-file tree 708453d64796eb617cb8a1602959e00356693315
Well, a tree is a container for files (which in turn consist of their
permissions, file names, and blobs).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Mon, Aug 20, 2007 at 10:39:57PM +0200, David Kastrup [off-list ref] wrote:
quoted
And it has permissions associated with these hashes.
No, with the files. Think again: the link between file system and
repository is the index, and the current index format has no
representation for trees or directories.
So git _can't_ store any information about a _directory_, since no
information about directories passes through the index.
If, as Jan suggested in a previous message, you introduce directories in
the index, I still don't see why you would need two entries in the tree
object...
quoted
(...)
quoted
quoted
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.
See what a raw tree object looks like:
git-cat-file tree 708453d64796eb617cb8a1602959e00356693315
Well, a tree is a container for files (which in turn consist of their
permissions, file names, and blobs).
The question here was why the permissions are encoded with "%06o" while
the hash is packed. Anyways, it's just a boring detail.
Mike
Mike Hommey [off-list ref] wrote:
quoted
quoted
quoted
quoted
sprintf "%06o %s\0%s", $mode, $file, pack("H[40]", $sha1)
The question here was why the permissions are encoded with "%06o" while
the hash is packed. Anyways, it's just a boring detail.
Because text format is simple and pretty much everyone understands
it, especially when you are talking about UNIX mode/permission
bits in octal, the name is "text", and then oh, wait, those 40
bytes of hex is a lot of data - we'll just make that 20 bytes of
binary instead. :-)
OK, I don't know if that's really true. Probably only Linus can
speak to why the tree format is what it is. Its just how I have
rationalized it myself.
Pack v4 changes the storage of the mode to be in binary, at least
within the packfile, but it does still have to convert it back to the
"%06o" format when computing the SHA-1 of a tree object. Believe it
or not, pack v4 is being worked on again... so maybe in a future
version of Git the tree modes will take up a tiny bit less space.
I haven't specifically looked at this, but I would also suspect that
within any given tree's zlib dictionary the mode string portion is
given a reasonably short bit sequence. So its doubtful that the
mode takes up 6 bytes when compressed by zlib, its probably more
likely around 1 byte. Pack v4's big win here isn't due to the mode,
its due to the filenames being compressed better across trees.
--
Shawn.