Re: [3/4] What's not in 1.5.2 (new topics)

It seems like a lot of the friction here is because people are trying to devise a single mechanism that will handle two distinct cases:

1. The location of a subproject's changed (the "public repository 
relocated to a different host" problem). This is not temporally 
sensitive -- if you check out an old version of the superproject, you 
need to look in the new location for the subproject. A local override 
for the subproject's location will likely still be perfectly valid.

2. The superproject no longer wants to use the same subproject; it wants 
to replace it with something else at the same point in the tree (the 
"version 2 of superproject uses the 2.6 kernel as opposed to the 2.4 
kernel"). This is temporally sensitive -- if you check out an old 
version of the superproject, you want to use the old location for the 
subproject too. A single local override will most likely not be valid 
for both versions.

I think these are fundamentally different operations and it's the desire to fold them into one mechanism that's leading to a lot of the discussion here. Would we simplify things by not conflating them?

For example -- and yes, this is partially a rehash of other people's ideas -- instead of mapping a subproject path directly to revision@URL, instead map it to revision@symbolic name. The symbolic name is then separately mapped to a URL, and it's that symbolic name that can be locally overridden. The mappings of symbolic names to URLs is unversioned; the mapping of subprojects to revision@symbolic is versioned. Local overrides happen at the symbolic->URL mapping.

So you'd have something like

version 1: kernel-src/ -> kernel24
version 2: kernel-src/ -> kernel26
unversioned:
    kernel24 -> git://whatever/2.4
    kernel26 -> git://whatever/2.6

And then locally, the override is:

    kernel24 -> git://myhost/2.4

When version 2 gets pulled down, you start off using the upstream's URL, which you know because you pulled down the new copy of the unversioned symbolic->URL map. Maybe git-pull gives you a warning like, "I see you have some overrides, so you might want to know about this new symbolic name too." With an appropriate option it might even stop before doing anything with the new symbolic name to give you a chance to override.

Maybe that has some problems I'm not seeing, but it seems like adding one more layer of indirection which has different versioning semantics would make this a more tractable problem.

-Steve