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

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

Their contents are.

That makes no sense to you and apparently quite a few other people, after a lot of explaining. That does not mean that it wouldn't work, but it does mean that it is going nowhere: it is irrelevant whether I consider the concept easy to understand and explain when nobody else does: that makes it unmaintainable.

Fortunately, a few other participants, notably Junio and Jakub, have focused a bit more on technical details rather than my sanity in their somewhat more nuanced feedback, and thus I have (in a separate thread) made a new proposal that addresses a few technical shortcomings and that does no longer require splitting tree-ness/directory-ness into separate concepts and records, something which I considered elegant and others gibberish.

It boils down to encoding the "don't-evaporate-when-empty" or "I told you to keep track of it" property in the directory access permissions: if those are zero, git does not track the corresponding directory and will attempt a remove-on-empty. If they are non-zero (probably 755 as long as git stores only a sanitized version of the actual state there), this means that git has been told to track the directory and will not attempt to delete it until it is told to stop tracking it again.

The proposal of allowing "." "!." as a gitignore pattern to specify the tracking/non-tracking indicator does still stand, but its semantics are now so much decoupled from that of "don't-evaporate-when-empty" that the code would not actually overlap with that of the tracking, and so discussing it is orthogonal to the actual proposal and can be postponed separately, and an implementation proferred separately once the rest is in place.

So do both of us a favor and skip the rest of the mail queue with "Empty directories..." in its title.

Actually, the code (and later comments for it) you produced matches the areas of work and what I think needs to be done quite closer now than with my original proposal.

So while the discussion with you has not really been much of a help except to show without reasonable doubt that my original approach would have been unmaintainable by other persons, the code _is_ very helpful.

Thanks,