Hi David, On Thu, Jul 19, 2007 at 13:31:50 +0200, David Kastrup wrote: > core.excludefile: . Really nice idea to give directories 'DIR/.' name. I'm sure there are several other ways to implement your proposal. But why to put in in Git itself? Decomposition and abstraction principle tells me that this should go to some other place. Please consider this: I myself use Git to track my own local projects, and for this usage you proposal have no value for me, i.e. as a _Source_ Code Management system Git is rather complete. But I also track /etc and ~/ in Git, and for this I'd love to have directories, permissions, ownership, other attributes, to be tracked. I have Perl script wrapping Git that allows me to filter tracked paths by full regexps instead of Git's file globs, and also to filter out too big files assuming that they are binary anyway. Most people solving the same problem moved further and implemented tools to store part of file system state (permissions and ownership) in a textual representation, to track that in Git. I'm sure you've seen such posts in the list. And my point is that rather than building the support for all of it into core Git, and then implementing sophisticated configuration to disable parts of it, wouldn't it be better to have a separate tools orthogonal to Git itself? At the extreme case (probably not really seriously), consider the following design: there are two layers, file system layer, and contents layer. On checkout file system layer creates (or examines existing) directory tree along with all files and their file system state (permissions, ownership, ACLs, attributes, ...), and then asks contents layer to update the contents. This way layers are independent, and file system layer may be implemented on top of pure contents tracking. File system layer may be extended to be made particular OS/FS dependent if some development team wishes so. Even hard links may be supported: since file system layer may deside to remember that two paths really reference the same inode (i.e. contents), contents layer may be asked to update the data only once with either file name/descriptor. This, BTW, is why I think not tracking file attributes when versioning, say, /etc, is not a big loss. When I will move to the new system, I will mostly be interested in contents diffs of the same configuration files in /etc. I will trust their new attributes, and will not want to restore them to what they were on the old system. So the essence of my objection is that we should not pollute core Git with file system state tracking more than it's required to know where to put the contents to. Everything else should go elsewhere. Again, I'd love to have your proposal be implemented, but only in a way that won't interfere with pure SCM's operations. -- Tomash Brechko - 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
