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

Junio C Hamano [off-list ref] writes:

Linus Torvalds [off-list ref] writes:

quoted

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. 

That is true if it is implemented as David suggested, to have a
phony "." entry in the tree object itself.  The object name of such
a tree (when it contains blobs and trees underneath) will be
different from a tree that contains the same set of blobs and trees.
It would destroy the fundamental concepts of git.

How so?

But you _could_ treat that "should-be-kept-even-when-empty"-ness
just like we treat executable bit on blobs, I think.

When blobs with the same contents but of different type (REG vs LNK)
and regular file with or without executable bit are entered in git,
they all get the same SHA-1 but we can still tell them apart because
the index and the tree entry have mode bits.  So hypothetically, you
could introduce "sticky" directory in tree entries to mark "this
will not go away when emptied".

A tree containing files with and without executable bits will show
different SHA-1 sums.  There is no reason that this should be
different for a tree containing the conceptual "." or not.  I won't
fight for a specific implementation but if I am going to implement
this (and the current lack of enthusiasm points to that) I will not go
and duplicate the entire ignore/add/rm/index/repository machinery in
order to have a bit rather than an actual "." directory entry.

Most Unix file systems have an honest, physical, down-to-Earth
directory entry "." even on disk because it _simplifies_ matters, even
though one could special-case "." all throughout and make do without a
physical entry in theory.

And, as I explained, "." lends itself perfectly to the gitignore
machinery in order to policy projects to track or not track
directories.

In a 'tree' object, they might appear as:

        40000 ordinary-directory '\0' 20-byte SHA-1
        41000 directory-dontremove-even-if-empty '\0' 20-byte SHA-1

In 'index', as your "I'm soft" patch, we do not have to add
nonsticky kind of tree nodes,

It does not work, since then you can't distinguish

mkdir A
touch B
git-add A/B

from

mkdir A
touch B
git-add A

It is very clear that git-rm A/B _mustn't_ leave an empty directory in
the first case, and _must_ leave an empty directory in the second case
_if_ and only if one tracks directories.

Obviously, this "sticky" bit will cascade up and make your otherwise
equivalent parent tree's different,

No, it must not "cascade up".  After

mkdir -p A/B
touch A/B/C
git-add A/B
git-rm A/B

there must be nothing tracked by git.  The "sticky" bit does not
"cascade up".  Its upward effect is only changing the SHA-1 of the
tree, like any change below does.

This will involve a lot of changes, so I would not recommend anybody
doing so, though.

Neither would I.  Why people want to complicate the code base
everywhere by avoiding to treat "." like a legitimate entry (as Unix
file systems do for a _reason_) is simply a miracle to me.

The framework is pretty much _there_.  There is no point in not making
use of it and duplicating the whole machinery because we want a "bit
set" implementation instead of a file name.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum