Simon 'corecode' Schubert <corecode@xxxxxxxxxxxx> writes:
> David Kastrup wrote:
>>> Otherwise you could have two very different trees that encode the
>>> same *content* (just with different ways of getting there -
>>> depending on whether you have a history with empty trees or not),
>>> and that's very much against the philosophy of git, and breaks some
>>> fundamental rules (like the fact that "same content == same SHA1").
>>
>> No, the content is _different_. One tree contains a tracked
>> directory, the other does not. That means that the trees behave
>> _differently_ when you manipulate them, and that means that they are
>> _not_ the same tree.
>
> You are mistaking things.
No, I am redefining them, or rather the view on them. Subtle
difference.
> Like the executable bit on a file is not content, the fact that a
> directory should be kept despite being empty is also an *attribute*
> of the directory. This is meta-data, not actual data (content).
We need to track it, anyway. So there is little point in not using
the existing infrastructure for handling named entities.
> So no matter how elegant tracking the "." entry might be (and I
> think it is, because it covers a lot of corner cases already), it
> puts the information at the wrong place.
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]
> That's sad, because otherwise it would be really elegant.
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.
--
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
