{"thread":{"id":"63574","subject":"issue with git submodules and a clone.defaultRemoteName different than origin?","startedAt":"2025-06-03T23:06:31Z","lastAt":"2025-06-07T05:43:42Z","messageCount":6,"participants":["Jacob Keller","Junio C Hamano","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"519612","messageId":"4f638125-39e0-43a1-9c58-35c2d433042f@intel.com","threadId":"63574","inReplyTo":null,"subject":"issue with git submodules and a clone.defaultRemoteName different than origin?","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2025-06-03T23:06:27Z","receivedAt":"2025-06-03T23:06:31Z","isPatch":false,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"Hi,\n\nI recently ran into an issue with git submodules because my\nclone.defaultRemoteName is not \"origin\":\n\n> fatal: 'origin' does not appear to be a git repository\n> fatal: Could not read from remote repository.\n> \n> Please make sure you have the correct access rights\n> and the repository exists.\n> fatal: Fetched in submodule path 'submodule', but it did not contain <redacted>. Direct fetching of that commit failed.\n\n\nThis appears to be due to the builtin/submodule--helper hard coding\n\"origin\" in \"repo_get_default_remote\".\n\nI am unsure what the best way to fix this is. I could have the function\nread the clone.defaultRemoteName, or I could have it check if there is\nonly one remote then use that.. or maybe add a new submodule remote name\noption?\n\nThoughts on what the best solution is here?\n\nI'm thinking the following:\n\n1) check if there is only one remote, then use that\n2) check clone.defaultRemoteName and use that otherwise\n3) fall back to origin otherwise?\n\nPerhaps we could insert a step 0 where we add a config option which will\nhave submodule clones use the given remote name + use that as the\ndefault when in detached head state?\n\nThanks,\nJake\n"},{"id":"519618","messageId":"xmqq1ps0gzo5.fsf@gitster.g","threadId":"63574","inReplyTo":"4f638125-39e0-43a1-9c58-35c2d433042f@intel.com","subject":"Re: issue with git submodules and a clone.defaultRemoteName different than origin?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-03T23:42:34Z","receivedAt":"2025-06-03T23:42:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller <jacob.e.keller@intel.com> writes:\n\n>> fatal: 'origin' does not appear to be a git repository\n>> fatal: Could not read from remote repository.\n>>  ...\n> This appears to be due to the builtin/submodule--helper hard coding\n> \"origin\" in \"repo_get_default_remote\".\n>\n> I am unsure what the best way to fix this is. I could have the function\n> read the clone.defaultRemoteName, or I could have it check if there is\n> only one remote then use that.. or maybe add a new submodule remote name\n> option?\n\nIs it is the nickname of the default remote that corresponds to\n'origin' in other/most peoples' set-up you are using for your\nsubmodules that is causing you?  And because you have\nclone.defaultRemoteName configured either in the superproject's\n.git/config or your personal ~/.gitconfig, when you activate\nsubmodules, the \"git clone\" used to populate your submodule\ndirectory from elsewhere would use that custom name?\n\nWhat I am trying to figure out by thinking aloud is if there a place\nwhere that custom name name is recorded anywhere in the submodule\nrepository (or superproject, but I somehow doubt it).\n\nThe clone.defaultRemoteName configuration variable can be overriden\nfrom the command line of \"git clone\", and even if the process to\nactivate a submodule does not let you pass the \"--origin\", you could\nhave updated your clone.defaultRemoteName, so the current value of\nthe configuration variable is pretty much useless.  \n\nYour \"if there is only a single remote\" would probably be a better\nway.  The only reason you are having trouble, if I am reading the\nrepo_get_default_remote(), is because you are on a detached HEAD.\nDo we know where that HEAD was detached from, perhaps from the\nreflog?  If we are on a concrete branch, there already is a logic to\nfigure out what branch from what remote it integrates with, and that\nwould give you the most reliable answer.\n\n> Thoughts on what the best solution is here?\n>\n> I'm thinking the following:\n>\n> 1) check if there is only one remote, then use that\n> 2) check clone.defaultRemoteName and use that otherwise\n> 3) fall back to origin otherwise?\n\nI'd insert 1.5 to figure out where your detached HEAD came from and\nuse that as if you are on that branch.  That is the source of the\nproblem, right?\n\n> Perhaps we could insert a step 0 where we add a config option which will\n> have submodule clones use the given remote name + use that as the\n> default when in detached head state?\n\nGoing forward, it would of course be the most reliable if we wrote a\ndistinct configuration variable in submodule repository when we\nactivate it, i.e. when \"git submodule update --init\" clones, it can\nrecord the nickname that was used, so that none of the 1-3) above\nmethods have to be used to guess what the name is.\n\nOr, perhaps we can update \"git submodule update --init\" so that when\nit clones, it ignores clone.defaultRemoteName configuration, so that\nthis codepath always can rely on the name being 'origin'.  If you\nare always accessing the submodule through the toplevel superproject,\nthe name used in the submodule does not make a difference, no?\n\n"},{"id":"519684","messageId":"48c2af0f-348a-4443-a8b7-74ea4b666bff@intel.com","threadId":"63574","inReplyTo":"xmqq1ps0gzo5.fsf@gitster.g","subject":"Re: issue with git submodules and a clone.defaultRemoteName different than origin?","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2025-06-04T17:18:44Z","receivedAt":"2025-06-04T17:18:49Z","isPatch":false,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"\n\nOn 6/3/2025 4:42 PM, Junio C Hamano wrote:\n> Jacob Keller <jacob.e.keller@intel.com> writes:\n> \n>>> fatal: 'origin' does not appear to be a git repository\n>>> fatal: Could not read from remote repository.\n>>>  ...\n>> This appears to be due to the builtin/submodule--helper hard coding\n>> \"origin\" in \"repo_get_default_remote\".\n>>\n>> I am unsure what the best way to fix this is. I could have the function\n>> read the clone.defaultRemoteName, or I could have it check if there is\n>> only one remote then use that.. or maybe add a new submodule remote name\n>> option?\n> \n> Is it is the nickname of the default remote that corresponds to\n> 'origin' in other/most peoples' set-up you are using for your\n> submodules that is causing you?  And because you have\n> clone.defaultRemoteName configured either in the superproject's\n> .git/config or your personal ~/.gitconfig, when you activate\n> submodules, the \"git clone\" used to populate your submodule\n> directory from elsewhere would use that custom name?\n> \n\nIn short: I set clone.defaultRemoteName in my .gitconfig to \"upstream\"\nbecause that fits more naturally for most of my repositories at work.\n\nBecause of this, when a submodule is initialized, it is cloned with a\nremote named \"upstream\" instead of \"origin\". (Either its cloned this\nway, or I later renamed it to this as in some cases)\n\nBy default \"git submodule update\" checks out submodules to a detached\nHEAD state.\n\nWhen git is trying to find the default remote for a submodule, it will\nbe in this detached HEAD state, so the fallback to \"origin\" fails\nbecause origin isn't a valid remote on my setup.\n\n> What I am trying to figure out by thinking aloud is if there a place\n> where that custom name name is recorded anywhere in the submodule\n> repository (or superproject, but I somehow doubt it).\n> \n\nThere isn't, other than the fact that there is a remote with that name\nbut not one named \"origin\".\n\nWe could possibly add a config option which we could have the\nsuperproject set when cloning to specify which remote is the one marked\nin the parents .gitmodules?\n\nAlternatively, we could have the parent record the remote name in its\n.gitmodules.. but that seems a bit odd since a user could later rename\nthat remote.\n\n> The clone.defaultRemoteName configuration variable can be overriden\n> from the command line of \"git clone\", and even if the process to\n> activate a submodule does not let you pass the \"--origin\", you could\n> have updated your clone.defaultRemoteName, so the current value of\n> the configuration variable is pretty much useless.  \n> \n\nMy idea was that its better to fall back to this as a default because\nits an indication that the default is not \"origin\".\n\n> Your \"if there is only a single remote\" would probably be a better\n> way.  The only reason you are having trouble, if I am reading the\n> repo_get_default_remote(), is because you are on a detached HEAD.\n> Do we know where that HEAD was detached from, perhaps from the\n> reflog?  If we are on a concrete branch, there already is a logic to\n> figure out what branch from what remote it integrates with, and that\n> would give you the most reliable answer.\n\n\nIt comes from the way git submodule update checks out the requested\ncommit in a detached HEAD state.\n\n> \n>> Thoughts on what the best solution is here?\n>>\n>> I'm thinking the following:\n>>\n>> 1) check if there is only one remote, then use that\n>> 2) check clone.defaultRemoteName and use that otherwise\n>> 3) fall back to origin otherwise?\n> \n> I'd insert 1.5 to figure out where your detached HEAD came from and\n> use that as if you are on that branch.  That is the source of the\n> problem, right?\n> \n\nThe issue is that the detached HEAD comes from the submodule update, and\nmay not actually be on any local branch. The parent project likely knows\nbased on its git modules, and we could actually maybe just look up the\nremote based on its URL actually...\n\n>> Perhaps we could insert a step 0 where we add a config option which will\n>> have submodule clones use the given remote name + use that as the\n>> default when in detached head state?\n> \n> Going forward, it would of course be the most reliable if we wrote a\n> distinct configuration variable in submodule repository when we\n> activate it, i.e. when \"git submodule update --init\" clones, it can\n> record the nickname that was used, so that none of the 1-3) above\n> methods have to be used to guess what the name is.\n> \n\nYea, this is a good idea.\n\n> Or, perhaps we can update \"git submodule update --init\" so that when\n> it clones, it ignores clone.defaultRemoteName configuration, so that\n> this codepath always can rely on the name being 'origin'.  If you\n> are always accessing the submodule through the toplevel superproject,\n> the name used in the submodule does not make a difference, no?\n> \n\nTrue, but I often need to make PRs for projects from a submodule, and in\nthat case the github CLI likes to rename origin as \"upstream\" and make\n\"origin\" be my fork. (Though I personally use \"upstream\" for the\nupstream project and \"fork\" for the fork.) In both case, origin no\nlonger exists.\n\nHowever, I had another thought while reading this:\n\nthe parent project already has a URL in its config. What if we updated\nthe logic to just directly use that URL instead of using a remote name?\nOr at the very least, we try to pick a remote based on the URL.\n"},{"id":"519878","messageId":"bdf7e50f-aa65-4514-b147-9f7ebed147ab@intel.com","threadId":"63574","inReplyTo":"48c2af0f-348a-4443-a8b7-74ea4b666bff@intel.com","subject":"Re: issue with git submodules and a clone.defaultRemoteName different than origin?","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2025-06-06T21:29:48Z","receivedAt":"2025-06-06T21:29:55Z","isPatch":false,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"\n\nOn 6/4/2025 10:18 AM, Jacob Keller wrote:\n> \n> the parent project already has a URL in its config. What if we updated\n> the logic to just directly use that URL instead of using a remote name?\n> Or at the very least, we try to pick a remote based on the URL.\n> \n\nI'm looking into this approach still, but I ran into some interesting\nissues with the remote.c logic which claims to work with any \"struct\nrepository *\", but ends up calling paths to that hard code the_repository.\n\nIt looks like those end up in the \"read_remotes_file\" and\n\"read_branches_file\" functions which are deprecated, and planned to be\nremoved in 3.0...\n\nWould patches to modify those to take a repository pointer in order to\nallow callers of read_config() to work properly with a submodule\nrepository be acceptable?\n\nI also saw that many functions take a remote_state structure, but if I\nwanted to make them submodule repo compatible I would need to either add\nor switch to passing a repo pointer. I'm not sure what the best method\nfor that is. Add parameters? We can get from repo to remote_state easily\nbut we can't go back, so it seems like just switching them to take repo\ninstead of remote_state would be sufficient.\n\nI wanted to use the remote.c helpers rather than re-inventing the logic\nfor reading the config to figure out remotes, both a) to find the\ncorrect remote by its URL and b) to find out if there is exactly 1 remote.\n"},{"id":"519881","messageId":"xmqq8qm41m62.fsf@gitster.g","threadId":"63574","inReplyTo":"bdf7e50f-aa65-4514-b147-9f7ebed147ab@intel.com","subject":"Re: issue with git submodules and a clone.defaultRemoteName different than origin?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-06T23:32:21Z","receivedAt":"2025-06-06T23:32:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller <jacob.e.keller@intel.com> writes:\n\n> It looks like those end up in the \"read_remotes_file\" and\n> \"read_branches_file\" functions which are deprecated, and planned to be\n> removed in 3.0...\n>\n> Would patches to modify those to take a repository pointer in order to\n> allow callers of read_config() to work properly with a submodule\n> repository be acceptable?\n\nThe recent trend has been that it generally is very much welcomed to\nfix such a code path that takes \"repo\" at an entry point but ends up\ndeep in its callchain to ignore it and use the_repository instead,\neven without a potential use case to benefit from such a change.\n\nYou have a concrete use case, so I would suspect it is even better\nthan \"acceptable\".  Patrick, what do you think?\n\n\nThanks.\n"},{"id":"519883","messageId":"aEPRiEdJ8c0X4HY5@pks.im","threadId":"63574","inReplyTo":"xmqq8qm41m62.fsf@gitster.g","subject":"Re: issue with git submodules and a clone.defaultRemoteName different than origin?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-06-07T05:43:36Z","receivedAt":"2025-06-07T05:43:42Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Jun 06, 2025 at 04:32:21PM -0700, Junio C Hamano wrote:\n> Jacob Keller <jacob.e.keller@intel.com> writes:\n> \n> > It looks like those end up in the \"read_remotes_file\" and\n> > \"read_branches_file\" functions which are deprecated, and planned to be\n> > removed in 3.0...\n> >\n> > Would patches to modify those to take a repository pointer in order to\n> > allow callers of read_config() to work properly with a submodule\n> > repository be acceptable?\n> \n> The recent trend has been that it generally is very much welcomed to\n> fix such a code path that takes \"repo\" at an entry point but ends up\n> deep in its callchain to ignore it and use the_repository instead,\n> even without a potential use case to benefit from such a change.\n> \n> You have a concrete use case, so I would suspect it is even better\n> than \"acceptable\".  Patrick, what do you think?\n\nI definitely agree, yes. It is a long road to get rid of\n`the_repository`. Taking many small steps on this road that have a\nproper motivation is way easier than doing large steps that get rid of\nthe variable for the sake of getting rid of it.\n\nPatrick\n"}]}