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

From: David Kastrup <dak@gnu.org>
Date: Jul 20, 2007, 05:35 UTC
Message-ID: <85644fvdrn.fsf@lola.goethe.zz>
In-Reply-To: <alpine.LFD.0.999.0707191726510.27249@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 17 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 9 quoted lines

> 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