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@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
