Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Sat, 21 Jul 2007, David Kastrup wrote: >> >> tree1: >> 0?0000 . -> dir1 >> 100644 a.c -> blob1 >> 040000 a -> tree2 >> 100644 abc -> blob3 > > No. Totally broken. That "." entry not only doesn't buy you > anything, it is *impossible*. You cannot make an object point to > itself. Not possible. It does not point to itself. The name "." points to an entry of type "dir", no content is involved. trees in the repository have content, and _only_ content. directories in the repository imply existence, and _only_ existence. > Tell me how to calculate the SHA1 for the result. Since "." has no content (as long as we don't decide to track any file permissions at one point of time), _all_ entries "." will have the same SHA1. > Also, tell me what the *point* is. There is none. The point is to have a reflection of the physical existence of a directory. Not just as a manner of accommodating slashes in a flat filespace, allowing certain slash-related operations to be carried out efficiently. >> Linus, a directory is simply non-existent inside of git. > > You need to learn git first. > > A directory doesn't exist IN THE INDEX (until my patches). But you > need to learn about the object database and the SHA1's. That's the > real meat of git, and it sure as hell knows about directories. I have written up a complete explanation about the underlying concept in a separate thread, maybe it would make sense reading that before investing too much time meddling over details that don't fit the large picture. The point is that the object database and the SHA1 values track _trees_, not _directories_. And a _tree_ is just a hashing mechanism in the repository for files. Its existence is solely dependent on the existence of its contents. The only synchronization with directories is that when a tree becomes empty, git attempts to do an rmdir on the corresponding directory. And of course, if git needs to check out a file, it creates the necessary parent directories. Now since the physical _contents_ of a directory are already tracked in _trees_ by git, the only missing part is the _existence_ of the directory itself: a directory must exist as long as there is a tree (and thus content) connected with it, but the reverse does not hold: without a tree, the directory can still exist. Which we can represent by a repository entry named "." without content (the content is already catered for by the _tree_). This must _not_ be represented by a _tree_ node since there is no content, and a tree without content by _definition_ does not exist. I must be really bad at explaining things, or I am losing a fight against preconceptions fixed beyond my imagination. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
