Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> So the whole notion of "remembering" whether a directory was added
> explicitly as an empty directory or not is just not a sensible concept in
> git.
That is true if it is implemented as David suggested, to have a
phony "." entry in the tree object itself. The object name of
such a tree (when it contains blobs and trees underneath) will
be different from a tree that contains the same set of blobs and
trees. It would destroy the fundamental concepts of git.
But you _could_ treat that "should-be-kept-even-when-empty"-ness
just like we treat executable bit on blobs, I think.
When blobs with the same contents but of different type (REG vs
LNK) and regular file with or without executable bit are entered
in git, they all get the same SHA-1 but we can still tell them
apart because the index and the tree entry have mode bits. So
hypothetically, you could introduce "sticky" directory in tree
entries to mark "this will not go away when emptied".
In a 'tree' object, they might appear as:
40000 ordinary-directory '\0' 20-byte SHA-1
41000 directory-dontremove-even-if-empty '\0' 20-byte SHA-1
In 'index', as your "I'm soft" patch, we do not have to add
nonsticky kind of tree nodes, but for "empty" ones, we can add:
041000 directory-dontremove-even-if-empty '\0' 20-byte SHA-1
in the index and (unlike your patch) keep it there even after a
blob or a tree is added underneath it.
The "sticky" bit on such a directory would have to obey the
usual rule of 3-way merge, which would be a huge change to do
so, but I do no see there is anything fundamental that prevents
you from doing this. Other than the fact that probably no git
long timer is interested in spending time on such a feature,
that is.
Obviously, this "sticky" bit will cascade up and make your
otherwise equivalent parent tree's different, but I think that
is just as a sane behaviour as two trees that contain the same
blob with only executable-bit differences have different names.
This will involve a lot of changes, so I would not recommend
anybody doing so, though.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
