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

[Andy Parkins <andyparkins@gmail.com>]

On Thursday 2007 May 17, Junio C Hamano wrote:

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

> 	[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?

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

> 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