On Sun, Jul 22, 2007 at 05:39:06PM +0200, David Kastrup wrote: > Now my proposal basically boils down to using the u+x bit on > directory/tree entries for tracking "keep around when empty". > > I think we are on the safe side to assume a directory with access > permissions zero (a-rwx) is something we never want to be able to > track with git. Ok, so I think you are still missing the fundamental issue about why Linus is upset with your proposals. One of the fundamental things which falls out of the "Git Tracks Contents" mantra is that information which you expect to be pushed forward future revisions (as opposed to metadata which is specific to a commit, such as the Author and Committer of a patch, the Commit log, etc.) *MUST* be information which is realized in the working tree. That way, if you diff between working trees, one of which has either your "." entry or your "u+x" bit, and of which doesn't, they need to be *different* when run "git diff" on the two working trees. Another way of putting is this single bit of information meaning "keep this directory around when empty" is something that ***must*** be representable in three different places: in a git tree object, in the index, *AND* in the working tree. The problem with "." is that since all directories contain the "." entry, you can't represent the bit of information you want to record in the working tree in that way. There is a same problem with using the u+x permission, for the same reason. Unless you want to make directories you want to keep around with access permissions of zero in the working tree, you're *still* not able to record presence or absence of the "keep around when empty bit" in the working tree. That's why the ".gitignore" entry is acceptable, where as your proposals are not. The absence or presence of the ".gitignore" entry in the working tree is a natural way of representing the "keep around when empty". So would a ".do_not_erase" file in the directory --- sort of like the "Do Not Erase" that professors would write on whiteboards in order to request janitors to not erase them. It seems that you are objecting to having something tangible written on the whiteboard --- or, in the directory, to indicate the "do not erase" note. But the problem is that Linus very much wants the "do not erase" bit to be visible in the working directory, since to do otherwise would violate fundamental design assumptions all over the git source files. Metadata such as the executable bit is actually stored in the working directory. But we can't store the "do not erase bit" by leaving the executable permission off, since that will prevent the directory from being useful. So your new proposal suffers from the same fundamental flaw as your previous one. Maybe you disagree with Linus's design constraint, but you've never addressed his specific concern on-point, which is that since Git Tracks Content, if you want something to be tracked across revisions, it must be visible in the working tree. That is, metadata in the sense of data which is not visible in the working tree, is not allowed to exist inside Git and carried across revisions. So fundamentally, Git does not currently today support "svn propset" in terms of setting metadata on a particular file which isn't visible in the working tree. With SVN, today you can use svn propset to what you could think of as extended attributes. So one proposal that you *could* try proposing is using extended attributes to represent arbitrary properties, including the one which you want, which is the "do not erase" property. And one of the arguments might be that this way we could better preserve arbitrary properties currently set inside SVN, so that such repository could be faithfully translated into a Git repository. The problem with such a proposal is that it now requires that the filesystem used to store the working directory MUST support extended attributes, and some filesystems, such as FAT filesystems, do not. And Git already has been accused of not being Windows friendly enough, and this would make things worse. It's also a lot of hair for two very marginal features, namely being able to support arbitrary SVN property values, and the "do not erase when empty" directory bit. Personally, I don't htink it's worth it, but at least using filesystem xattrs to store that one bit of information would at least be faithful to the fundamental git design principal. Regards, - Ted - 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
