Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> On Thu, 19 Jul 2007, Linus Torvalds wrote:
>>
>> That's physically impossible with the git data-structures (since
>> there is no way of saving "this directory was added empty" in the
>> tree structures, nor any point to it), so I think it's just insane
>> rambling.
>
> Of course, it's physically *possible* to have a tree that contains
> two entries for the same name: first the "empty tree" and then the
> "real tree", and yeah, in theory you could track things that way.
>
> So I guess the "physically impossible" was a bit strong. You'd have
> to have a totally insane format, and you'd have to violate deeply
> seated rules about what trees look like (and the index too, for that
> matter: we'd have to do the same for the index, and keep the S_IFDIR
> entry alive despite having other entries that are children of it),
> but it's *possible*.
Excuse me? You don't need a "totally insane format". You need an
entry "." of a new type "directory" that can be part of the current
concept of a "tree". This new type does _not_ have children. It is
not a container for files. It would be the thing that would carry
permissions or other properties if git were to store them. It can be
put into .gitignore files like other files.
One drawback is that adding and removing it alone is not supported
with the current git-add and git-remove commands: they would require
an additional argument "-d" like "ls" does.
All of this is a straightforward extension fitting very well the
current paradigms and also existing file systems and their usage.
> It's just a really bad idea.
> So to be sane, when you add files, the empty directory entry has to
> go away.
You really have not followed the discussion at all. This is not
possible since otherwise you could not distinguish the cases
mkdir A
touch A/B
git-add A
git-rm A/B
where A was added and not removed and should stay and
mkdir A
touch A/B
git-add A/B
git-rm A/B
where a single file was added and removed and nothing should stay.
> 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.
> In fact, that may be the best way to explain why it's *not* an
> option to have "empty trees remain empty trees if we remove the last
> file from them": git fundamnetally tracks "content snapshots", and
> anything that implies the content containing any history is against
> the rules.
>
> So the whole notion of "remembering" whether a directory was added
> explicitly as an empty directory or not is just not a sensible
> concept in git.
Certainly. That is why we instead remember whether or not a directory
entry "." was added or not. It will be added (unless the defaults and
gitignore settings ask "." to be non-tracked) when git adds the
corresponding tree or subtree, and it will get removed when git
removes the corresponding tree or subtree. Emptiness is not a special
case, and it can't be. Currently, the main information associated
with "." is "stay around even if tree becomes empty".
Now you can do
unlink .
in Solaris and have the name "." vanish while the directory still
works as a container by other names.
I don't propose that git be able to track this difference, though, and
I doubt that most file archivers would.
But git can or cannot ignore files, and in a similar way it can or
cannot ignore what a directory has more than being an abstract
container.
--
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
