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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html