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

On Sat, Jan 21, 2017 at 7:53 AM, Brian J. Davis [off-list ref] wrote:

On 1/19/2017 7:22 PM, Stefan Beller wrote:

quoted

quoted

quoted

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.

quoted

quoted

quoted

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