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

From: Petr Baudis <pasky@suse.cz>
Date: May 17, 2007, 17:30 UTC
Message-ID: <20070517173005.GS4489@pasky.or.cz>
In-Reply-To: <20070517162542.GA28501@coredump.intra.peff.net>

On Thu, May 17, 2007 at 06:25:42PM CEST, Jeff King wrote:

Show 10 quoted lines

> However, I think we _must_ have an override mechanism, since I don't
> necessarily use the same URLs that you do. I propose that such overrides
> should go into the local repo config. The only difference between what I
> have proposed and what Junio mentioned is that I would base the config
> override key on the directory name, not the URL. This means that if
> upstream changes their pointer to the URL, yours will change with it
> _unless you have an override_. With Junio's, their change of URL will
> override your change (since the key will no longer match your config).
> 
> How do you propose to handle overrides?

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.

Show 8 quoted lines

> > "kernel/" has _no_ meaning. Only a (treeid,"kernel/") pair has meaning,
> > nothing less - a particular tree contains a submodule in given subtree.
> > Different trees can have different submodules in different subtrees.
> 
> Right. In my proposal (unlike Alex's), it _is_ tied to the tree, since
> that tree has a particular .gitmodules. But I also think you should be
> able to override the submodule URL for kernel/ _for all time_ if you
> want.

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

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett