Andy Parkins wrote:
Bear in mind that what you're suggesting is no different in implementation from what Junio is suggesting but with one difference: in Junio's option the "identifier" will act as a default URL if no override is found.
I don't like using the URL as the key for one simple reason: while it technically doesn't conflate the two cases of "I want to use a different code base for this subproject starting in version X of the superproject" and "I want to use the same code base I've been using all along, but it has moved" (in that you can, as you point out, simply map the old URL to a new one independent of the project's history) it does encourage people to conflate the two in their minds.
Relatively few users will look at an identifier that is a valid URL and think of it as anything but a URL, especially if, in the absence of any overrides, the software (from the user's perspective) treats it as a URL. The override capability is almost certain to remain obscure since you won't need to use it in the normal case. Therefore, when the submodule's home gets moved to a different host, the first thing a lot of people are going to think to do is not to leave the submodule's identifier (the original URL) alone and create a mapping config entry, but rather to change the submodule to use a brand-new identifier that happens to be the same as the new URL. At which point you're right back to the original problem of checking out an old version of the superproject and having it point to a now-nonexistent subproject.
That's why I suggested making the identifiers look nothing like URLs, though of course to the extent they're arbitrary strings, one could use a URL if one chose to. I don't object to the *capability* of using a URL as an identifier in a three-level scheme like I described -- it would be silly to forbid -- but I think it would be a dangerous convention to establish because it will eventually encourage people to shoot themselves in the foot for lack of knowing what's actually going on.
-Steve - 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
