Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]

["Brian J. Davis" <bitminer@gmail.com>]

On 1/17/2017 12:43 PM, Stefan Beller wrote:
> On Sun, Jan 15, 2017 at 1:02 PM, Brian J. Davis <bitminer@gmail.com> wrote:
>
>>> Technically it is submodule.<name>.url instead of
>>> submodule.<path>.url. The name is usually the path initially, and once
>>> you move the submodule, only the path changes, the name is supposed to
>>> be constant and stay the same.
>> I am not certain what is meant by this.  All I know is I can use my
>> "directory_to_checkout" above to place in tree relative from root the
>> project any where in the tree not already tracked by git.  You state name
>> instead of path, but it allows path correct? Either that or I have gone off
>> reservation with my use of git for years now. Maybe this is a deviation from
>> how it is documented/should work and how it actually works?  It works great
>> how I use it.
> Yes name can equal the path (and usually does). This is a minor detail
> that is only relevant for renaming submodules, so ... maybe let's not
> focus on it too much. :)
>
>>>>
>>>> but if say I want to pull from some server 2 and do a
>>>>
>>>> git submodule update --init --recursive
>>> That is why the "git submodule init" exists at all.
>>>
>>>       git submodule init
>>>       $EDIT .git/config # change submodule.<name>.url to server2
>>>       git submodule update # that uses the adapted url and
>>>       # creates the submodule repository.
>>>
>>>       # From now on the submodule is on its own.
>>>       cd <submodule> && git config --list
>>>       # prints an "origin" remote and a lot more
>>>
>>> For a better explanation, I started a documentation series, see
>>>
>>> https://github.com/gitster/git/commit/e2b51b9df618ceeff7c4ec044e20f5ce9a87241e
>>>
>>> (It is not finished, but that is supposed to explain this exact pain
>>> point in the
>>> STATES section, feel free to point out missing things or what is hard
>>> to understand)
>> I am not sure I got much out of the STATES section regarding my problem.
> Your original problem as far as I understand is this:
>
>    You have a project with submodules.
>    The submodules are described in the .gitmodules file.
>    But the URL is pointing to an undesired location.
>    You want to rewrite the URLs before actually cloning the submodules.
>
> And to solve this problem we need to perform multiple steps:
>
>    # --no is the default, just for clarity here:
>    git clone <project> --no-recurse-submodules
>    # The submodules are now in the *uninitialized* state
>
>    git submodule init
>    # the submodules are in the initialized state
>
>    git submodule update
>    # submodules are populated, i.e. cloned from
>    # the configured URLs and put into the working tree at
>    # the appropriate path.
>
> Between the init and the update step you can modify the URLs.
> These commands are just a repetition from the first email, but the
> git commands can be viewed as moving from one state to another
> for submodules; submodules itself can be seen as a state machine
> according to that proposed documentation. Maybe such a state machine
> makes it easier to understand for some people.

"Between the init and the update step you can modify the URLs."  Yes I can and have to... wish it was not this way.

>>>> what I would get is from someserver1 not someserver2 as there is no
>>>> "origin"
>>>> support for submodules.  Is this correct?  If so can origin support be
>>>> added
>>>> to submodules?
>>> Can you explain more in detail what you mean by origin support?
>> Yes so when we do a:
>>
>> git push origin master
>>
>> origin is of course the Remote (Remotes
>> https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)
>>
>> So I best use terminology "Remotes" support.  Git push supports remotes, but
>> git submodules does not.  The basic idea is this:
>>
>> If Git allowed multiple submodule
>> (https://git-scm.com/book/en/v2/Git-Tools-Submodules) Remotes to be
>> specified say as an example:
>>
>> git submodule add [remote] [url]
>>
>> git submodule add origin https://github.com/chaconinc/DbConnector
>> git submodule add indhouse https://indhouse .corp/chaconinc/DbConnector
>>
>> Where:
>>
>> [submodule "DbConnector"]
>>      path = DbConnector
>>      url = https://github.com/chaconinc/DbConnector
>>
>> Could then change to:
>>
>> [submodule "DbConnector"]
>>      path = DbConnector
>>      remote.origin.url = https://github.com/chaconinc/DbConnector
>>      remote.origin.url = https://indhouse .corp/chaconinc/DbConnector
> here I assume there is a typo and the second remote.origin.url should be
> remote.inhouse.url ?
yes second should have read remote.inhouse.url:

[submodule "DbConnector"]
     path = DbConnector
     remote.origin.url = https://github.com/chaconinc/DbConnector
     remote.inhouse.url = https://indhouse.corp/chaconinc/DbConnector

>>
>> Then it should be possible to get:
>>
>> git submodules update --init --recursive
> which would setup the submodule with both
>
> [remote "origin"]
>    url = https://github.com/..
> [remote "inhouse"]
>    url = https://inhouse.corp/..
>
> But where do we clone it from?
> (Or do we just do a "git init" on that submodule and fetch
> from both remotes? in which order?)
origin by default and inhouse if specified. There is already a implied 
default (origin). The idea was not to do both but rather what is 
specified.  Origin and inhouse are just names for remotes. If one wanted 
a "--all-remotes" could pull from everywhere in the Ether if feature was 
to be implemented.
>> To support
>>
>> git submodules update [remote] --init --recursive
> This would just clone/fetch from the specified remote?
> If implementing this, we may run into a collision with the
> specified submodules, what if a submodule is at
> path "origin" ?
>
> Does "git submodule update origin --init --recursive"
> then mean to update the single "origin" submodule or
> all submodules from their origin remote?
Yes. That is what I would think.  It does this already by default. It's 
not as though submodules were/are all that well thought out to begin 
with in git IMO.
>> And thus allow
>>
>> git submodules update origin --init --recursive
>>
>> git submodules update indhouse --init --recursive
> understood. I like the idea of being able to specify
> multiple remotes from the superproject..

Yes so do I!  It *could* be better than the current offering which is 
defaulted origin.