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

From: David Kastrup <dak@gnu.org>
Date: Jul 19, 2007, 09:54 UTC
Message-ID: <86k5swen1w.fsf@lola.quinscape.zz>
In-Reply-To: <85zm1tue6a.fsf@lola.goethe.zz>

David Kastrup <dak@gnu.org> writes:

Show 40 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.
>
>>  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