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

From: Stefan Beller <sbeller@google.com>
Date: Jan 24, 2017, 18:49 UTC
Message-ID: <CAGZ79kZzekMc=pUN3Q2+zmaSNo-BLJ6TxaQPN8ik1B2+ACy9dw@mail.gmail.com>
In-Reply-To: <04fe8035-dbf0-83d2-c465-f746b99ce609@gmail.com>

On Sat, Jan 21, 2017 at 7:53 AM, Brian J. Davis <bitminer@gmail.com> wrote:

Show 62 quoted lines

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

Show 28 quoted lines

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