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

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

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

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.