On 1/17/2017 12:43 PM, Stefan Beller wrote:
On Sun, Jan 15, 2017 at 1:02 PM, Brian J. Davis <bitminer@xxxxxxxxx> 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.