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