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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 20, 2007, 19:24 UTC
Message-ID: <alpine.LFD.0.999.0707201210550.27249@woody.linux-foundation.org>
In-Reply-To: <7vk5svxt1f.fsf@assigned-by-dhcp.cox.net>

On Fri, 20 Jul 2007, Junio C Hamano wrote:

Show 8 quoted lines

> 
> 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.

Having thought about it a bit more, I would absolutely *detest* any kind of "executable bit" like behaviour.

Why?

Merging. I think one of the fundamental issues in merging is that you do it "in the working tree". This is something that pretty much *everybody* else gets wrong, and it's somethign where git absolutely shines.

But git shines here exactly because git never tracks "history" or the state in the tree, and only ever tracks things that are indubitably real content. Which is why you never *ever* have to tell git about "I moved file X to file Y" - because git only tracks things that it can see right in front of it, in the tree.

The "sticky directory" bit simply would not be something like that. It simply isn't "content", and as such, it should not be tracked. It's as easy as that. We don't want a merge of two branches to have to specify any extra data "outside" the tree as to how it should be merged.

So the issue about whether a directory *exists* or not can be merged (just look at the tree), but the issue about whether the directory is supposed to be sticky is something that you'd have to tell git about *outside* of the tree, and that violates the whole point of working tree merges.

I do realize that if you use inferior operating systems, we already have these kinds of "outside the tree" data entries, thanks to issues like symlinks and normal file executable bits that you would have to explicitly tell git about when you're working in a broken environment. So in that sense, it wouldn't be anything technically new for git.

But that doesn't change the fundamental issue: the limitation with executable bits and symlinks is a limitation of the broken environment, not of git. But "directories stay around after the last file is gone" is not that, it would simply be a design mistake in git itself.

There are other reasons to not do it. What about file renames? Maybe the directory got *renamed*. From a pure content angle, this is "all the files in that directory went away". If you have stupid rules like "directories stay around even though all the files went away", you would again have problems with this common case.

In other words: I don't care one whit about the whiners. What's MUCH more important than some random whiny person saying "Daddy, daddy, I want a pony" is whether you can afford to maintain that pony in the future. And this pony is just stupid.

So here:

	No, you cannot have a pony. NOT YOURS.

but I still think we should support the concept of importing things from other systems, and thus eventually support empty directories. Just not any crazy semantics with sticky histories.

			Linus

PS. As usual, per-user or per-repository *local* attributes are something else. They aren't "sticky history", they are just purely behavioural defaults. Those kinds of things may make sense. But that's not a "tracking content" issue.