Jonathan Nieder wrote: > What do you think of .gitignore and .gitattributes? Should they be > somewhere other than the filesystem as well? I would argue that .gitignore and .gitattributes are done right. They are integrated into a very mature part of git-core very well, and their nature is fundamentally different from that of .gitmodules. .gitignore and .gitattributes specify extended globs (see: wildmatch) rules to apply on the worktree, and can be in multiple places in the worktree. They apply strictly on the current worktree; they have nothing to do with the index, and have no interaction with other objects in the repository. Now, you might argue that they should be part of the tree object, but I will disagree because they don't operate on concrete entries in the tree but rather extended globs that match worktree paths. .gitmodules, on the other hand, specifies fundamental repository composition: it should be a special object in the tree precisely because it changes the fundamental meaning of one concrete tree entry. It has nothing to do with path treatment in the worktree, and hence has nothing to do with .gitattributes or.gitignore. > I don't think Jens had any obligation to work on submodules and > nothing else for the last five years. ;-) I know. What I'm saying is that his current approach is just filled with tons of unnecessary complexity, inelegance, and pain. This is evidenced by the fact that the current submodule system is pathetic after five years of work (and I don't think the developers working on it were particularly incompetent or lazy). > If you end up convincing others that your tools are worth working > on and those tools pleasantly take care of the same workflows that > submodules do, then I imagine people will be happy to migrate. Yes, I'm planning a strict superset of the current submodule system features. After some thought, I've decided not to have any feature regressions in my first version for merge (although that means a lot of work for me). > Speaking only for myself, I actually prefer the submodule UI, despite > not being thrilled with the > single-.gitmodules-file-at-the-root-of-the-worktree feature. So I > will not be working on your proposed redesign, unless it evolves > enough to be as pleasant a UI as (the long proposed UI of) submodules. I'm very interested in building a pleasant UI. I've always been a person who cares deeply about UI: this is evidenced by my recent remote.pushdefault patch, and my pull.autostash WIP. -- 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