On Thu, May 17, 2007 at 07:30:05PM +0200, Petr Baudis wrote: > I think Junio's URL keying works fine. Their change of URL will override > your change, but that is bad thing only when the old upstream's URL > changed, but the upstream stays the same. Then either the problem is > clearly visible or it will result only in somewhat suboptimal behaviour. > > OTOH, if the _upstream_ changed and your override scheme is at work, you > won't notice at all and simply will continue to use the same old > upstream. Right. But I think it makes more sense for the error condition to go the other way (that is, your override might get stale, but it will always be an _override_). You'll notice eventually anyway when upstream moves to a commit sha1 that you don't have in your submodule repo (or if they never do, that means your override tree actually _is_ valid, and didn't need to be changed anyway; this would be the case if upstream moved to a different mirror, but you were already using an alternate source anyway). > But again - "kernel/" means nothing, only "kernel/ in tree X". kernel/ > might point to linux-2.4 in older trees, linux-2.6 in newer trees, -mm > in the experimental branch and freebsd tree in the weirdo branch. Such > an override is _never_ going to work in the general situation, only when > "kernel/" always in all commits on all branches points to the same > single project. (You can work that around by at least making the setting > branch-specific, but that still doens't take into account the history, > and then newly created branches won't have the override you want, etc.) My point is that we _already_ have a mechanism that unambiguously points to the linked commit, and it's _not_ the URL; it's the commit sha1 embedded in the tree. Everything else is just a hint about where we might find that commit. -Peff - 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
