From: Brian J. Davis Date: Thu, 19 Jan 2017 23:11:53 GMT Subject: Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix] Message-ID: In-Reply-To: On 1/17/2017 12:43 PM, Stefan Beller wrote: > On Sun, Jan 15, 2017 at 1:02 PM, Brian J. Davis wrote: > >>> Technically it is submodule..url instead of >>> submodule..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..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 && 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 --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.