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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
