Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Sun, 22 Jul 2007, David Kastrup wrote: >> Make it have an empty reference, and it is unique. > > I *really* don't see the point. > > And you seem to have igored totally my treatise on "content" and how > the stuff git tracks must be stuff that is visible and detectable in > the trees. 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. > And if I understand you correctly, you also wouldn't be backwards > compatible. 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. > IOW, there's a lot of "why's" at all levels. > > I don't see the *point*. What's the problem you're trying to solve? 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. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
