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

[Steven Grimm <koreth@midwinter.com>]

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