Re: [RFC PATCH] Re: Empty directories...

[David Kastrup <dak@gnu.org>]

Linus Torvalds <torvalds@linux-foundation.org> 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