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
-
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
