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

[Jeff King <peff@peff.net>]

On Thu, May 17, 2007 at 06:10:02PM +0200, Petr Baudis wrote:

> But, did you read what you actually quoted? Because I can only repeat my
> argument in the face of (1), and you didn't seem to dispute any part of
> it at all.

You said:
> Because kernel/ can get removed, moved around, or point at entirely
> *different* projects over time and branches - kernel/ can switch from
> linux-2.4 to linux-2.6, libc/ can switch between glibc and uClibc, ...

which I took to mean that we must be able to track changes to the URL
which is pointed to by the kernel/ submodule, and therefore this
configuration must be in a tracked file.  Which is _precisely_ what I
advocated: it goes in a .gitmodules (or .gitconfig) file in the tracked
directory. This is counter to what Alex says, which is that one should
simply pull the config down during clone time and never change it.

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?

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

-Peff