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

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:

No, I am redefining them, or rather the view on them. Subtle difference.

We need to track it, anyway. So there is little point in not using the existing infrastructure for handling named entities.

I don't see that the place is wrong: after all, that is where Unix places "." too, and for good reason. I was arguing for _separating_ the concept of "directory" and "tree" in the repository. The tree is a container entity defined exclusively by its contents (which determine its hash). That is how git already does things. There is _no_ connection with the physical existence of a directory: in the work directory, git creates and deletes directories as a _side-effect_ of storing and removing trees. But git itself does not track directories as a physical entity at _all_. If you had a flat filesystem allowing slashes in filenames, git would get along better than it does now, without ever creating or removing a directory. Trees are just a convenient selection and pattern matching mechanism for files as far as git is concerned. The correspondence to physical directories in the work directory is a nuisance rather than an asset as far as git is concerned.

In a recent thread here, tags with slashes were supported by essentially doing

    mkdir -p "`dirname $TAG`"
    touch $TAG

where directory creation is just a side effect of supporting slashes. And that, if you look closely, is git's current relation with directories altogether. The directories in the work file system are created by git just as a side effect for representing slashes, which in turn facilitate a certain manner of pattern matching.

And "." seems perfectly well suited to bring across the point that there actually is _physical_ existence associated with a directory, existence that remains when the rest of the tree is gone and _makes_ a difference to what the tree is, because it has a _different_ representation in the work file system.

Storing it as an _attribute_ of the tree is a bad idea, since then the simple rule "a tree without contents is empty" needs an exception. And a tree stops becoming just a container of its contents and all sort of new exceptions creep up.

There are some systems where the difference between directory as a file and directory as a structuring method are more apparent than under Unix (some utilities like rsync differentiate between A/B and A/B/ to bring across that difference).

Here is an example for some Emacs function concerned with the concept:

    directory-file-name is a built-in function in `C source code'.
    (directory-file-name DIRECTORY)

    Returns the file name of the directory named DIRECTORY.
    This is the name of the file that holds the data for the directory DIRECTORY.
    This operation exists because a directory is also a file, but its name as
    a directory is different from its name as a file.
    In Unix-syntax, this function just removes the final slash.
    On VMS, given a VMS-syntax directory name such as "[X.Y]",
    it returns a file name such as "[X]Y.DIR.1".

    [back]

If something is not elegant because of the angle of view, change the view. And it is not like the different angle has no predecessors or no consistency.