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

Linus Torvalds <torvalds@linux-foundation.org> writes:

Oh please. Just because you refuse to read a point-to-point reply does not mean it has not been made.

"." _is_ visible and detectable in every tree. But that does not mean it is automatically tracked by git unless it gets added explicitly, or implicitly (as long as the gitignore mechanism does not kick in) by adding a higher level directory.

If a file does not get added explicitly or implicitly, it does not end up in the repository and git behaves like it knows nothing about it.

And that's just the way it is going to be with directories. Nothing more, nothing less, nothing new.

Define backwards compatible. Anyway, you are the repository wizard: here are the semantics I need supported for backwards compatibility:

I need an entry type in the index and in the repository with the following features:

a) if part of a tree, the tree is not considered empty.  Should be
   easy.
b) it has the name ".".  This is not absolutely necessary, but it
   means that the gitignore mechanism can be used for dealing with it,
   and that's intuitive and has exactly the expressive power required
   for the job.  Now the gitignore mechanism is isolated very locally
   in dir.c: whether one makes the actual representation in the
   repository based on an attribute like "filemode" rather than on a
   separate entry does not actually complicate the code all too much.
   There is, however, some level of complication since the consulted
   .gitignore file for ignoring "." must, of course, be the .gitignore
   file situated _in_ the directory.  So making "." sit _in_ the tree
   rather than _on_ the tree simplifies the code considerably.  It is
   a small amount of code, nevertheless, so it is not a major
   strategic decision.

   One conceivable implementation would be indeed similar to what the
   "filemode" thing does: let us keep open the option to track, at one
   time, permissions.  The current format has, as far as I understand,
   all zeros in the permissions field of trees (I have not checked,
   though).  Now if we stipulate that this is the kind of directory
   permissions we will in all eternity _not_ support outside of git,
   we are all set with regard to backwards compatibility: a tree with
   permissions all zero will behave as previously: it will get removed
   when it becomes empty (taking the corresponding work tree directory
   with it, if possible).  And that's it.  But a tree with nonzero
   permissions (whether they correspond to outward permissions or are
   just a placeholder) will _not_ evaporate when becoming empty.  It
   will be possible to explicitly or implicitly delete it: that will
   just set its permissions all to zero so that it has the chance to
   evaporate next time it becomes empty.

rm -rf ./* git-commit -m "all empty" -a unzip /tmp/something-with-empty-dirs.zip git-add . git-commit -m "something-with-empty-dirs" git-checkout HEAD~1 # Now I don't want empty directories and their parents lying around. git-checkout master # Now the state after unzip should be restored faithfully rm -rf ./* unzip /tmp/something-else-with-empty-dirs git-commit -a -m "something-else" # Now I want to have the state of something-else registered faithfully # even if it contains top-level files and directories not present in # something-with-empty-dirs, because supposedly . is being tracked, # not just every file element in it.

Actually, oops. This last criterion is not met when .'s relation to the tree is such that it is only considered _part_ of tree.

Looks like it might be prudent to focus on the permissions-coupled representation.