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

[Junio C Hamano <junkio@cox.net>]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Friday 18 May 2007, Andy Parkins wrote:
>> Bear in mind that what you're suggesting is no different in implementation 
>> >from what Junio is suggesting but with one difference: in Junio's option 
>> the "identifier" will act as a default URL if no override is found.
>
> Yes; actually, its exactly the same aside from the name used in .gitmodules
> for it, as I proposed a default URL which is derived from the suproject identifier
> if no config entry is found.
>
>> > Again, we could have a default URL in the absence of this config entry
>> > which is relative to the URL of the superproject, and which allows for the
>> > superproject repository to act as proxy.
>> 
>> This is why Junio's option of URL=Key is better.

There is one thing that three-level thing Steven Grimm suggested
solves cleaner that my strawman would not.

If the superproject is about building a live-cd that hosts two
different systems, one BSD and the other Linux, you would have:

	kernel-bsd/ subproject pointing at http://some.bsd.org/
        kernel-linux/ pointing at http://www.kernel.org/kernel/

Now suppose kernel.org people forgot to renew the domain
registration and BSD people are quick to react, takes over the
nice "kernel.org" domain, and now the latter URL becomes a site
about the BSD kernel---what happens? ;-) URL=Key scheme uses the
URL as the key so newer kernel-bsd/ subproject may be pointed at
by http://www.kernel.org/kernel/ in the superproject after such
a transition.  Linux kernel wouldn't cease to be served, so
in your .git/config you will a map to tell git to fetch from the
new location http://www.linux-kernel.org/kernel, but what key
would you use?  Using http://www.kernel.org/kernel/ would not be
correct as it would work only for older parts of the history.
Newer part of the history would want to map the same URL (=Key)
to http://www.kernel.org/kernel which is now hosting the BSD
kernel.

In short, you would need to be able to express the "intent" in
the .gitmodules and say "I am talking about the Linux kernel
with this entry", and if the same URL used for that purpose is
ever retargetted to house something different that is also used
in your superproject, URL=Key scheme is screwed.

Also I would be lying if I said I do not like the three-level
thing --- that was one of the options I considered before the
URL=Key thing.  Steven's three-level thing does not have the
above problem (but there is one thing you need to be careful
about, which I'll mention at the end of this discussion).

> It all depends on how we construct the default URL out of the subproject
> identifier. Options:
> (1) do not try to construct a default URL at all. Error out without a config
> (2) use a configurable rewriting scheme like s/(.*)/git://host/\1/
> (3) automatically detect a senseful rewriting scheme
>
> Let's start with (1). We can invent convenient default schemes later on.

My preference is to stay at (1), and even if we are to do the
later steps, do it _always_ with confirmation from the user.

Fetching from a new URL (not just "different from what is
defined in .gitmodules") is a major deal from security point of
view (you should not fetch from stranger you do not trust).

There is one thing that I sense was misunderstood by some people
about my original strawman.  Entries in .git/config are _not_
used as an override.  They _are_ the only thing that are used.

Let's forget the above "BSD takes over kernel.org" example,
which was a tongue-in-cheek, and go back to the original
appliance release #1 and #2 uses kernel 2.4 and 2.6 example.

When you see this in .gitmodule:

 	[subproject "kernel/"]
         	URL = git://git.kernel.org/pub/linux-2.4.git
 
you can be in three states:

 (1) You haven't known about this subproject's URL.

 (2) You have already known about this subproject, and you
     earlier decided not to clone it nor check it out (i.e. in
     your working tree, kernel/ subdirectory is left empty).
     By default, you do not want to be bothered by this
     subproject.

 (3) You have known about this subproject, and you earlier
     decided that you are interested in it.  You have a
     repository and working tree that represents the subproject
     checked out in your kernel/ subdirectory.  By default, you
     want to keep track of this subproject.

Obviously in the initial-clone case you can only be in state
(1).  After the initial clone, if the upstream changed the
kernel/ binding to point at 2.6 kernel tree, you are also in the
same state (1).

In these cases, since the upstream clearly states that they are
now talking about a project unknown to you so far, or talking
about a different project (it could be just a new location for
the same thing, the case Steven's three-level thing can help you
to differenciate with this), I DO NOT want git to automatically
say "Ok, that's the new location" and blindly start following.

An unattended pull (actually, the checkout step after a pull)
SHOULD error out.

An interactive case should give an easy way for the user to
express his preference: (a) I do not care about this subproject,
(b) I do want to have this cloned and checked out, and the
suggested URL in .gitmodules would work fine for me, or (c) I do
want to have this, but I want to use this other URL because I
have a local mirror already.

I wrote in my original strawman to have these two entries in the
.git/config file:

 	[subproject "git://git.kernel.org/pub/linux-2.4.git"]
         	URL = http://www.kernel.org/pub/linux-2.4.git
 
The example mapped the URL=Key to a different URL, which gave a
false impression that I was only talking about override, but
that was my fault.  My intention was to use the _presense_ of
subproject.$URL section in .git/config as a way to detect state
(1), so when the user says "I do want to follow this subproject
and the .gitmodules URL is Ok" (iow, choice (b) above), you
would have an identical "mapping" there:

 	[subproject "git://git.kernel.org/pub/linux-2.4.git"]
         	URL = git://git.kernel.org/pub/linux-2.4.git

That's not an "override".  Lack of these two lines does not mean
you will blindly follow kernel/ subproject using the URL
recorded in .gitmodules file; it means you haven't decided what
to do about the kernel/ subproject yet.

If the user wants to say "I am not interested" (iow, choice (a)
above), we would not have URL section, but explicit variable to
say "I am not interested" there, like this:

 	[subproject "git://git.kernel.org/pub/linux-2.4.git"]
         	ignored

Then the presense of this section tells us that we are not in
state (1) about this subproject.

The above can easily be rewritten to use Steven's three-level
scheme, which I tend to think would work better.  But if we were
to do that, I think the .git/config section should give you a
way to differentiate not just known/unknown subprojects but also
a way to differentiate known/unknown URLs.

IOW, .gitmodules in three-level scheme might say:

	[subproject "kernel/"]
        	name = linux-2.6
                URL = git://git.kernel.org/pub/linux-2.6.git

and your .git/config would say:

	[subproject "linux-2.6"]
                URL = http://www.kernel.org/pub/linux-2.6.git
                seen = git://git.kernel.org/pub/linux-2.6.git

so that when the upstream .gitmodules changed the suggested URL
to "git://git.or.cz/pub/linux-2.6.git", the UI can say:

	The project uses "linux-2.6" project at kernel/
	subdirectory as subproject, we already know that you are
	interested in tracking it, that you have been tracking
	it with http://www.kernel.org/pub/linux-2.6.git URL.
	The upstream suggests a new URL you haven't seen, which is
	"git://git.or.cz/pub/linux-2.6.git".  Do you want to
	adjust the URL to follow this subproject?

The user may say yes and tell git to use http:// instead, in
which case the section in .git/config would become:

	[subproject "linux-2.6"]
                URL = http://git.or.cz/pub/linux-2.6.git
                seen = git://git.kernel.org/pub/linux-2.6.git
		seen = git://git.or.cz/pub/linux-2.6.git

After that, if the upstream wags the entry .gitmodules back to
point at git.kernel.org/, you already know about that repository
and the UI does not have to ask you what to do about it.  That's
made possible by using URL=Key in my strawman, but needs to be
done by this extra 'seen' multi-value variables in the three-level
scheme.