Re: issue with git submodules and a clone.defaultRemoteName different than origin?

[Junio C Hamano <gitster@pobox.com>]

Jacob Keller <jacob.e.keller@intel.com> writes:

>> fatal: 'origin' does not appear to be a git repository
>> fatal: Could not read from remote repository.
>>  ...
> This appears to be due to the builtin/submodule--helper hard coding
> "origin" in "repo_get_default_remote".
>
> I am unsure what the best way to fix this is. I could have the function
> read the clone.defaultRemoteName, or I could have it check if there is
> only one remote then use that.. or maybe add a new submodule remote name
> option?

Is it is the nickname of the default remote that corresponds to
'origin' in other/most peoples' set-up you are using for your
submodules that is causing you?  And because you have
clone.defaultRemoteName configured either in the superproject's
.git/config or your personal ~/.gitconfig, when you activate
submodules, the "git clone" used to populate your submodule
directory from elsewhere would use that custom name?

What I am trying to figure out by thinking aloud is if there a place
where that custom name name is recorded anywhere in the submodule
repository (or superproject, but I somehow doubt it).

The clone.defaultRemoteName configuration variable can be overriden
from the command line of "git clone", and even if the process to
activate a submodule does not let you pass the "--origin", you could
have updated your clone.defaultRemoteName, so the current value of
the configuration variable is pretty much useless.  

Your "if there is only a single remote" would probably be a better
way.  The only reason you are having trouble, if I am reading the
repo_get_default_remote(), is because you are on a detached HEAD.
Do we know where that HEAD was detached from, perhaps from the
reflog?  If we are on a concrete branch, there already is a logic to
figure out what branch from what remote it integrates with, and that
would give you the most reliable answer.

> Thoughts on what the best solution is here?
>
> I'm thinking the following:
>
> 1) check if there is only one remote, then use that
> 2) check clone.defaultRemoteName and use that otherwise
> 3) fall back to origin otherwise?

I'd insert 1.5 to figure out where your detached HEAD came from and
use that as if you are on that branch.  That is the source of the
problem, right?

> Perhaps we could insert a step 0 where we add a config option which will
> have submodule clones use the given remote name + use that as the
> default when in detached head state?

Going forward, it would of course be the most reliable if we wrote a
distinct configuration variable in submodule repository when we
activate it, i.e. when "git submodule update --init" clones, it can
record the nickname that was used, so that none of the 1-3) above
methods have to be used to guess what the name is.

Or, perhaps we can update "git submodule update --init" so that when
it clones, it ignores clone.defaultRemoteName configuration, so that
this codepath always can rely on the name being 'origin'.  If you
are always accessing the submodule through the toplevel superproject,
the name used in the submodule does not make a difference, no?