David Kastrup <dak@xxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> 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 - 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
