Jacob Keller <jacob.e.keller@xxxxxxxxx> 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?
