git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: problem w/recursive, submodules?

From
TBTorpey, Bill <bill.torpey@broadridge.com>
Date
Apr 4, 2025, 19:42 UTC
Message-ID
<PH0PR20MB6183CD9646B42F0DD552166792A92@PH0PR20MB6183.namprd20.prod.outlook.com>
In-Reply-To
<9274ED7A-0267-43E3-9AE1-DC0BBEC81E69@gmail.com>
- I'm afraid that we're unable to expose the internal repo because of co. policies.  Other than wrapper scripts for our internal dev. environment, the only thing of note in the internal repo is the .gitmodules file, which consists of the following:
[submodule "staging"]
	path = src
	branch = staging
	url = https://github.com/nyfix/OpenMAMA-omnm.git
- We've found that the problem is avoided if we execute the following command *after* doing the recursive clone.  Not sure why this is necessary -- shouldn't the recursive clone handle that on its own?
git submodule update --remote --recursive
- It sounds like you're suggesting that we need to go into the submodule and manually checkout a specific commit?  Shouldn't the recursive clone pick up the HEAD of the submodule branch?
If it sounds like we don't quite understand what git is doing here, that's a fair statement ;-)  In particular, only the submodule branch is exposed to us, but it sounds like git internally stores the commit hash instead?
Thanks again for your help!
________________________________________
From: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
Sent: Friday, April 4, 2025 10:59 AM
To: Torpey, Bill <Bill.Torpey@broadridge.com>
Cc: git@vger.kernel.org <git@vger.kernel.org>
Subject: Re: problem w/recursive, submodules?
 
This Message Is From an Unknown Sender
You have not previously corresponded with this sender.
 
> $ git clone -v -b master --recursive ssh://git@<internal>/nyfix/OpenMAMA-omnm.git

It's harder to understand the problem without being able to reproduce it. Do you have another example with public repositories?

> The commit hash from the recursive clone is the hash of a different (more recent) commit:

If I understood it correctly, it looks to me that it's another case of one of the most common misconceptions about submodules: they always reference a specific commit instead of branch or the latest commit.

If you want your repository to reference other commit of your submodule, you'll need to manually change this and commit this change. One way you can do that:

cd <submodule> git checkout <new commit of the submodule> cd - git add <submodule> git commit

Note that you'll need to do that every time you want you want your repository to reference other commit of the submodule.

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Previous: Lucas Seiki OshiroNext: Lucas Seiki Oshiro
Message 3 of 4 in “problem w/recursive, submodules?”
  1. Torpey, BillApr 3, 2025
  2. Lucas Seiki OshiroApr 4, 2025
  3. Torpey, BillApr 4, 2025
  4. Lucas Seiki OshiroApr 4, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.