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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 20, 2007, 10:34 UTC
Message-ID: <7vk5svxt1f.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46A08006.4020500@fs.ei.tum.de>

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:

Show 7 quoted lines

> You are mistaking things.  Like the executable bit on a file
> is not content, the fact that a directory should be kept
> despite being empty is also an *attribute* of the directory.
> This is meta-data, not actual data (content).  So no matter
> how elegant tracking the "." entry might be (and I think it
> is, because it covers a lot of corner cases already), it puts
> the information at the wrong place.

Actually, I do not think there is absolute right or wrong here. The difference is not that the information is at the "right" or "wrong" place, but one approach places the information at more efficient-to-use place than the other. In that sense, the attribute approach _is_ a more elegant solution between the two.

Making it an attribute has a huge practical advantage.

By treating executable bit as a piece metadata, we can compare the "contents" quickly. If you "chmod +x" a blob without changing anything else, we can detect that fact, because blob object names are equal. At the philosophical level, you _could_ argue that the executable-ness is one bit of content and include that in the object name computation for the blob. There is nothing fundamentally wrong about that approach, but that destroys the nice "cheap comparability" between blobs that differ only by executable-ness.

David's "." in tree is essentially the same argument as treating the executable-ness as one extra bit of content. The fact that a particular tree wants to stay even after emptied can be treated as part of contents (thereby reflected in its object name). There is nothing fundamentally wrong there, either. But that means two trees that contain otherwise identical set of blobs and subtrees, but differ only in the behaviour of when they are emptied, would get different object names, hence you need to descend into them to see if they are different.

Using attribute that is detached from the content itself allows you to hoist that one bit one level up. By treating executable-ness not as part of content, we can compare two blobs with different executable bits cheaply. You can avoid descending into such a tree when comparing it with another tree that is different only by the "will-stay-when-emptied"-ness the same way.