On Wed, Apr 20, 2016 at 8:14 PM, Yaroslav Halchenko <yoh@xxxxxxxxxxxxxx> wrote:
> NB Thank you for the lively discussion!
>
> On Wed, 20 Apr 2016, Stefan Beller wrote:
>
>> >> So currently the protocol doesn't allow to even specify the submodules
>> >> directories.
>
>> > Depends on what you exactly mean by "the protocol", but the
>> > networking protocol is about accessing a single repository. It is
>> > up to you to decide where to go next after learning what you can
>> > learn from the result, typically by following what appears in
>> > the .gitmodules file.
>
>> Right. But the .gitmodules file is not sufficient.
>
> why?
What do you expect from cloning a repo with submodules?
In case of a bare repo:
Get the repo from the specified remote and get the submodules
from "somewhere" (and .gitmodules helps you guessing where
"somewhere" is).
This has been the traditional way, and the .gitmodules file
is just a helper for a best guess where to get a submodule sha1
from. (The repo pointed at from the .gitmodules file may not exist
any more; or it may have forgot the wanted commit)
In case of non bare:
Get the repo and all its submodules from the specified remote.
(As the submodule is right there, that's the best guess to get it from,
no need to get it from somewhere else. The submodule at the remote
is the closest match you can get for replicating the superproject with
its submodules.)
This way is heavy underutilized as it wasn't exercised as often I would
guess, so the "wrong" default (to obtain the submodule information from
.gitmodules instead of from the remote directly) was not pointed out before.
Now that the client wants to make a decision where to get the
submodules from, based on the bare-ness of the remote, it may
require changes in the wire protocol, such that the remote simply
advertises it is a (non-)bare repository when you clone the superproject
from it. Then the client can make a better decision where to get the
submodules from.
>
>> >...<
>
>> I think on a hosting site they could even coexist when having the
>> layout as above.
>
>> top.git/
>> top.git/refs/{heads,tags,...}/...
>> top.git/objects/...
>> sub.git/
>> sub.git/refs/{heads,tags,...}/...
>> sub.git/objects/...
>
>> # the following only exist in non bare:
>> top.git/modules/sub.git/
>> top.git/modules/sub.git/refs/{heads,tags,...}/...
>> top.git/modules/sub.git/objects/...
>
>> The later files would be more reflective of what you *really*
>> want if you clone from top.git.
>
> may be there is no need for assumptions and .gitmodules should be
> sufficient?
>
> - absolute url in .gitmodules provides absolute URL/path to the
> submodule of interest, regardless either submodule is present in
> originating repository as updated submodule. Either cloning it
> instead of original repository would be more efficient is already a
> heuristic which might fail miserably (may be I have a faster
> connection to the original repository pointed by the absolute
> url than to this particular repository)
>
> - relative url in .gitmodules provides relative location to the location
> of the "top" repository, and that is only when that submodule "absolute"
> url should be resolved relative to the one of the "top" repository
I think the .gitmodules file is not sufficient for the following reason:
* As a "downstream" user you cannot change remote locations without
altering the history. Maybe you just want to have a mirror of some cool
open source project without the hassle to always merge and maintain changes
in your local submodules configuration. (c.f. git config url.<base>.insteadOf
for repos, just for submodule specific)
>
> NB I will consider it a separate issue either relative paths
> without '../' prefix are having any sense in bare repositories.
I guess it is a separate issue.
>
> or have I missed the point?
> --
> Yaroslav O. Halchenko
> Center for Open Neuroscience http://centerforopenneuroscience.org
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
> WWW: http://www.linkedin.com/in/yarik
--
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