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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 20 Jul 2007, Junio C Hamano wrote:
> 
> 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.