Jonathan Nieder wrote: > I quite like .git/modules/<subproject name> (for some reasons that > I've mentioned in other threads) and don't consider it nonsense, which > makes me assume I don't understand the goal of this patch, either. > Please don't take that personally. There's nothing to take personally, Jonathan. We're designing software, and the rationale for choosing a design is never "Jonathan personally likes this particular design, so therefore we'll go with it", but rather "Ram's design is objectively superior, and therefore we'll go with it". I'll proceed with bashing .git/modules, while your job is to defend it: 1. The path to the object store of a submodule depends upon how deeply it is nested in other submodules, and hence how many /modules/ components to add to the path to the project's name. Presumably, this is to avoid conflicts: but it's an overkill for such a simple job. In the 98% case, I never have two submodules with the same name in my superproject; for the 2% case, I can live with the inconvenience of naming a directory by hand, rather than putting up with this ugliness. 2. This ugliness complicates implementation of add/ rm/ mv, because each of them will have to know about this contrived path solution. 3. The paths in the gitfiles in various submodules is horribly ugly with tons of ../ components. This is especially the case in deeply nested submodules. We can't use an absolute path, because the superproject directory can be moved anywhere in the filesystem. 4. To relocate the object store and reuse it elsewhere is almost impossible. What if I want to remove the submodule, but work on it independently from the superproject? Re-clone? My solution fixes all these problems, and we need .git/modules/<name>.git (no path-to-submodule nonsense) only as a last resort: #3 (ref: my email to Peff). -- 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