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

David Kastrup [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

Another issue I thought about was what you would do in the step
3 in the following:

 1. David says "mkdir D; git add D"; you add S_IFDIR entry in
    the index at D;

 2. David says "date >D/F; git add D/F"; presumably you drop D
    from the index (to keep the index more backward compatible)
    and add S_IFREG entry at D/F.

I don't think that one should drop D here.  Operation 1 _is_ not
backward compatible, so if you want to revert it, you should
explicitly remove D.  And we can't "keep" the index backward
compatible if it isn't so after step 1.

quoted

 3. David says "git rm D/F".

Have we stopped keeping track of the "empty directory" at this
point?

The case I am worrying about is rather

mkdir D
mkdir D/E
touch D/E/file
git add D
[*]
git rm D/E/file

From a user perspective, E should be registered still.  Compare this
with

mkdir D
mkdir D/E
touch D/E/file
git add D/E/file
[*]
git rm D/E/file

Let's take this through the motions with my last proposal: at the
first [*], the index now contains

D/.        [dir]
D/E/.      [dir]
D/E/file   [file]

After git rm D/E/file, it contains

D/.        [dir]
D/E/.      [dir]

Compared with the second, where we just have in the index

D/E/file   [file]

and it is gone again after the remove.

After commiting in the first case, we have in the repository
D          [tree]
D/.        [dir]
D/E        [tree]
D/E/.      [dir]
D/E/file   [file]

Now we do
git rm D/E, and the index contains

D/E/.      [remove dir]
D/E/file   [remove file]

If we commit now,
D/E        [tree]
becomes empty and is removed.  All that stays is

D          [tree]
D/.        [dir]

So we still have [tree] items only in the repository, not in the
index, and there is no such thing as an empty tree.  But directories
have a presence in index and repository.  They are not containers of
files, that role is retained by trees.  Rather they are siblings of
the files in their associated tree.

As a note aside: if one wanted to track directory permissions, one
would track them in the [dir] entries, not in the [tree] entries.
Trees remain abstract structuring entities in the repository that
don't have an outside representation.  Directories will be
auto-created and deleted as necessary in the work directory to
facilitate having a place for checking tree elements out and in.

This means that
git add D/E/file
would _not_ track permissions of D and E (nor their existence).

However, Linus is right that permissions are something to be discussed
separately.  But separating [tree] and [dir] makes for a plausible and
understandable way of treating them.

-- 
David Kastrup