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

On Sun, Jan 15, 2017 at 1:02 PM, Brian J. Davis [off-list ref] wrote:

quoted

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

quoted

quoted

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.

quoted

quoted

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 ?

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

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?

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