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

[Andy Parkins <andyparkins@gmail.com>]

On Friday 2007 May 18, Josef Weidendorfer wrote:

> However, I think the usage of "url"/"url hint" as the 1st level subproject
> identifier really is badly misleading and confusing for users; it would be
> better for this identifier to not look like a URL at all. But by naming it
> "url" in .gitmodules, the user is tempted to put an URL at this place.

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.

Yours:

.gitmodules:
  kernel mykernelsubprojectid
.git/config
  [subproject "mykernelsubprojectid"]
     url = git://host/blah/blah.git

Junio's:

.gitmodules:
  kernel git://oldhost/blah/blah.git
.git/config
  [subproject "git://oldhost/blah/blah.git"]
     url = git://host/blah/blah.git

There is no difference between these two in terms of implementation.  Both 
assign a key to the "kernel" submodule then use that key to look up an 
override.  The advantage of Junio's suggestion is that when an override is 
not needed the key itself is used and therefore it Just Works (tm) with no 
change to the .git/config necessary.

> And why not use the .gitattributes for the ".gitmodules" needs?

I can't think of a reason why not; I think that's a separate question though.

> 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.  You are relying on the 
default being correct in order for a simple clone to work.  The relative path 
scheme you propose as a default, while logical, doesn't match anything that 
anyone does right now.  Look at any server that hosts multiple projects; they 
are stored flat not deep:

 project1/
 project2/
 project3/

One advantage of submodule support is that multiple supermodules can contain 
the same submodule, so you really can't force a hierarchical representation 
on the world just to make the default URL correct.

 project2/
  project1/
 project3/
  project1/

Oops.

> As relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie.
> if the superproject is at git://git.kernel.org/pub/super.git, the above
> subproject would default to the URL
> git://git.kernel.org/pub/super.git/subproject/linux24 which could be a
> symlink on the server.

I'm really uncomfortable with the idea of relying on directory structure 
passed the root repository path; from the
 git://git.kernel.org/pub/super.git/
point onwards; we don't have any right to expect that this is a real directory 
tree.  As an example; svn URLs don't match up with what's on disk:

 svn://svnhost/pub/repo/trunk/src
                       ^^^^^^^^^^

On disk there is no such directory as /trunk/src under the repository 
directory.  In the same way, even technically what you suggest would work, 
the part of the URL under git://git.kernel.org/pub/super.git/ is git's own 
namespace - it's not the users to mess with.  E.g. if I had a subproject 
called "refs" you'd be in trouble.

> To support different subproject repositories linked in at the
> same path of a superproject, Nicolas noted that we would have to replace
> the subproject repository at top/kernel/.git (taking my example above)
> whenever we cross the subproject change boundary in a checkout (e.g. from
> linux24 to linux26). The natural thing here would be to have
> subproject repositories at a seperate place, like inside of the
> superproject repository such as at ".git/subproject/linux24", which works
> well with my default interpretation of relative subproject paths above. At
> checkout, the correct repository would be bound by a symlink:

Your objection to the url=key scheme was lack of simplicity - to me the above 
is significantly more complex and is relying far too much on the submodule 
being on the same server as the supermodule.  Big mistake.  A typical use of 
submodules would be to integrate someone else's project, not your own, nor 
indeed your own checkout of that project.  Why should I have to keep my own 
copies of, say, kernel2.4 and kernel2.6 when there are perfectly acceptable 
URLs to the real repositories?

> > 2. Suppose .gitmodules in upstream tree points at subproject repo at
> > kernel.org, and I clone from there - my repo will point at kernel.org by
> > default? But now, I'd like everyone who clones from *my* repo to get
> > pointed at *my* server by default (e.g. for mirroring),
> > but would not changing .gitmodules create a commit so my
> > head will now differ from upstream  - so it won't be signed properly
> > etc... Did I misunderstand something?
>
> No, that is correct. Supporting a relative URL specification as proposed
> above should solve this issue.

I think that's the wrong solution.  A change of source URL for a submodule 
from what upstream uses to your own server is a _fork_ from upstream, 
therefore you would fork your own branch in your supermodule and 
alter .gitmodules to point at your server.  Everybody is happy, and the fork 
is recorded.

The override system is only there for the local repository (which always takes 
precedence) not for the server provider to hide detail from those checking 
the repo out.



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