On Sat, Jan 21, 2017 at 7:53 AM, Brian J. Davis <bitminer@xxxxxxxxx> wrote: > > On 1/19/2017 7:22 PM, Stefan Beller wrote: >>>> >>>> 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. >> >> So how would yo u rather want to do it? >> look at the .gitmodules file beforehand and then run a "submodule update" >> ? >> Or a thing like >> >> git -c url.https://internal.insteadOf git://github.com/ \ >> -c submodule.record-rewritten-urls submodule update >> >> (no need for init there as theoretically there is not >> need for such an intermediate step) >> > "Yes please and thank you" ... both. > > My thought was to simply allow addition to .gitmodules. If I understand > correctly you are proposing, to override these at the command line and > possibly rewrite them on submodule update, but maybe not save or add to > .gitmodules. I would then propose both. > 1) allow user to add to .gitmodules for those who do not care that > "outsiders" know the internal dev server > and > 2) allow to rewrite while not saving to .gitmodules on fresh clone and > submodule update for thoes that do not want ousiders to known internal dev > server. > and possibly: > 3) allow at command line to add remote to .gitmodules on submodule commands > (note add optoin in -c <name> = <value> pair) > > .gitmodules before: > > [submodule "subprojects/wrangler"] > path = subprojects/wrangler > url = git://github.com/ > > Then your adapted command: > > git -c url.https://internal.insteadOf git://github.com/ \ > -c submodule.record-rewritten-urls=add,internal --add submodule > update > > would produce > > [submodule "subprojects/projname"] > path = subprojects/projname > remote.origin.url = git://github.com/ > remote.internal.url =https://internal.insteadOf > > Or similar support. I think this was avoided until now as it would rewrite/add history. So what if you want ot "just mirror" a large project with a lot of submodules? You would want to do that without touching the history, hence we'd need to do such a configuration in a separate place. IIRC there was a proposal to have a ref e.g. "refs/submodule/config", that can overwrite/extend the .gitmodules file with your own configuration. It is a ref, such that mirroring would work, but not part of the main history, such that yoiu can still change it. I think to get it right we need to enable a workflow that allows easy "multi-step" mirroring, e.g. A (source of truth) can be mirrored to B, who can overlay the .gitmodules to point to server-B, which then can be mirrored by C, who can have its own serverC. When C forgot to configure all the submodules, it should fall back to serverB as that was closest, and if that is unconfigured it should fallback to A IMO. > >>>> [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. >> >> How is origin implied to be the default? >> Should there be an order (e.g. if you cannot find it at inhouse get it >> from github, >> if they are down, get it from kernel.org) > > As it is in the Highlander series... "there can be only one" (remote). So > that is what I mean by origin. The only remote allowed is the "origin" > unless changed by the user... but there can still only be one *currently*. > Though I see your point as it is not labeled "origin". It is not labeled at > all. Apologies for confusion there. "origin" is just a common name for a remote, like "master" is a common name for branches. There is nothing inherently special about these except for their automatic setup after cloning/initializing a repo. So you can delete the master branch (which I did in a project that I am not the authoritative maintainer of; I only have feature branches), and the repository just works fine.