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

From: Andy Parkins <andyparkins@gmail.com>
Date: May 17, 2007, 07:51 UTC
Message-ID: <200705170851.26548.andyparkins@gmail.com>
In-Reply-To: <7v4pmcauu3.fsf@assigned-by-dhcp.cox.net>

On Thursday 2007 May 17, Junio C Hamano wrote:

Show 7 quoted lines

> I think that depends _WHY_ the URL recorded .gitmodules are
> updated.  It would perfectly be reasonable for release #1 of an
> appliance project to bind linux 2.4 tree at kernel/ subdirectory
> while release #2 source to have 2.6 one; they come from two
> different repository URLs.  When you seek the superproject back
> to release #1, you would still want to fetch from 2.4 upstream
> if you are updating.

That's a very good point; I hadn't considered that there was a case for recording a change.

> What I was "handwaving" (or "envisioning") was to have something
> like this in .gitmodules:

Sorry, "handwaving" was a bit rude - I certainly didn't mean that you weren't supplying sufficient detail for the circumstance; I meant that in the sense of the tricky bits being papered over with user overrides and questions about which URL to /really/ use. The fact that you even felt it necessary to mention those overrides signals, I think, that something is wrong.

Show 5 quoted lines

> 	[subproject "kernel/"]
>         	URL = git://git.kernel.org/pub/linux-2.4.git
>
> (or 2.6, depending on the revision of the superproject) and per
> repository configuration would maps this with these two entries:

So now - running with your example - I'm in a project with a 2.6 URL in .gitmodules and config; now I check out a past revision. .gitmodules is updated to show the URL at that time (2.4) - what happens to config, which must have higher precedence? Am I meant to update that myself? So, as I hop around between branches you expect that I will be updating the config file for each checkout?

Show 5 quoted lines

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

Now this part I love.  _That_ is a proper solution.  To me though, these are a 
completely different category from the [subproject] above.  I think that 
should be highlighted with a different section name like "[urlmap]".

Show 5 quoted lines

> The intent is
>
> 	(1) "kernel/" directory is found to be a gitlink in the
>             tree/index; .gitmodules is consulted to find the
>             "URL", which is just a handle and the initial hint

In which case that [subproject "kernel/"] section is not needed (I think it would be better to simply say "URL not found for submodule kernel/" or something if there is no .gitmodules rather than supplying that override).

> 	(2) That "initial hint" is used to look up the
>             subproject entry from the configuration, to find the
>             "real" URL that is used by this repository

Yes.  Excellent; the "hint" now becomes a lookup key into the url mappings.

> which hopefully is already answered by the above handwaving ;-).

Absolutely. I'm very impressed. It solves both the temporal and spatial changes problem because one can remap every URL that was ever used in the history of the .gitmodules file if one wanted.

Show 9 quoted lines

> in your .git/config.  After the repository migrates to
> git.sf.net, you would update that existing entry and also add
> another entry, so that .git/config would have these two entries:
>
> 	[subproject "git://git.or.cz/sub.git"]
>         	URL = git://git.sf.net/sub.git
>
> 	[subproject "git://git.sf.net/sub.git"]
>         	URL = git://git.sf.net/sub.git

I don't suppose the second one is needed; wouldn't the default be $key = $url, when no override is found?

This also raises the point that these mappings would probably be order-dependent; because it may be that I want to do:

  [subproject "git://git.or.cz/sub.git"]
    URL = git://git.sf.net/sub.git

  [subproject "git://git.sf.net/sub.git"]
    URL = /home/andyp/git/mycopyofsub.git

In conclusion: I think that's a first class solution to the problem (and probably what you had in mind all along, and me screaming around wasn't helpful :-)).

Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com