* problem w/recursive, submodules?
@ 2025-04-03 14:48 Torpey, Bill
2025-04-04 14:59 ` Lucas Seiki Oshiro
0 siblings, 1 reply; 4+ messages in thread
From: Torpey, Bill @ 2025-04-03 14:48 UTC (permalink / raw)
To: git@vger•kernel.org
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
(We've got a setup where our internal git repos provide wrapper scripts etc. for our
environment and then pull in open-source projects, some of which we contribute to and others
which we sponsor directly. We've been using submodules to make that work and de-couple
the internal bits from the open-source bits).
Cloned a repo including a submodule:
$ git clone -v -b master --recursive ssh://git@<internal>/nyfix/OpenMAMA-omnm.git
Cloning into 'OpenMAMA-omnm'...
remote: Enumerating objects: 789, done.
remote: Counting objects: 100% (789/789), done.
remote: Compressing objects: 100% (461/461), done.
remote: Total 789 (delta 498), reused 472 (delta 323), pack-reused 0
Receiving objects: 100% (789/789), 492.75 KiB | 970.00 KiB/s, done.
Resolving deltas: 100% (498/498), done.
Submodule 'staging' (https://github.com/nyfix/OpenMAMA-omnm.git) registered for path 'src'
Cloning into '/Users/bill.torpey/temp/stash/OpenMAMA-omnm/src'...
remote: Enumerating objects: 916, done.
remote: Counting objects: 100% (127/127), done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 916 (delta 63), reused 105 (delta 49), pack-reused 789 (from 1)
Receiving objects: 100% (916/916), 563.50 KiB | 444.00 KiB/s, done.
Resolving deltas: 100% (594/594), done.
Submodule path 'src': checked out '7bb809da9746051b96c0448f8137f25eaf8c15d1'
Noticed that the commit hash of the submodule does NOT match the commit hash when the submodule is cloned directly:
$ git clone -v -b staging https://github.com/nyfix/OpenMAMA-omnm.git
Cloning into 'OpenMAMA-omnm'...
POST git-upload-pack (377 bytes)
POST git-upload-pack (gzip 1559 to 810 bytes)
remote: Enumerating objects: 916, done.
remote: Counting objects: 100% (127/127), done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 916 (delta 63), reused 105 (delta 49), pack-reused 789 (from 1)
Receiving objects: 100% (916/916), 563.50 KiB | 454.00 KiB/s, done.
Resolving deltas: 100% (594/594), done.
$ cd OpenMAMA-omnm
$ git status
On branch staging
Your branch is up to date with 'origin/staging'.
nothing to commit, working tree clean
$ git rev-parse HEAD
a092be3bc330f53f644b53d80881bf30cadd367f
What did you expect to happen? (Expected behavior)
I expected the commit hash to be correct (a092be3bc330f53f644b53d80881bf30cadd367f) in both
the recursive clone and the direct clone.
What happened instead? (Actual behavior)
The commit hash from the recursive clone is the hash of a different (more recent) commit:
$ git switch release/1.0.0b
branch 'release/1.0.0b' set up to track 'origin/release/1.0.0b'.
Switched to a new branch 'release/1.0.0b'
$ git rev-parse HEAD
7bb809da9746051b96c0448f8137f25eaf8c15d1
What's different between what you expected and what actually happened?
The commit hash in the recursive clone is wrong.
Anything else you want to add:
Nope - just, thanks for taking a look.
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.49.0
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
libcurl: 8.6.0
zlib: 1.2.12
uname: Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000 arm64
compiler info: clang: 16.0.0 (clang-1600.0.26.6)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: problem w/recursive, submodules?
2025-04-03 14:48 problem w/recursive, submodules? Torpey, Bill
@ 2025-04-04 14:59 ` Lucas Seiki Oshiro
2025-04-04 19:42 ` Torpey, Bill
0 siblings, 1 reply; 4+ messages in thread
From: Lucas Seiki Oshiro @ 2025-04-04 14:59 UTC (permalink / raw)
To: Torpey, Bill; +Cc: git@vger•kernel.org
> $ 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: problem w/recursive, submodules?
2025-04-04 14:59 ` Lucas Seiki Oshiro
@ 2025-04-04 19:42 ` Torpey, Bill
2025-04-04 21:58 ` Lucas Seiki Oshiro
0 siblings, 1 reply; 4+ messages in thread
From: Torpey, Bill @ 2025-04-04 19:42 UTC (permalink / raw)
To: Lucas Seiki Oshiro; +Cc: git@vger•kernel.org
- 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: problem w/recursive, submodules?
2025-04-04 19:42 ` Torpey, Bill
@ 2025-04-04 21:58 ` Lucas Seiki Oshiro
0 siblings, 0 replies; 4+ messages in thread
From: Lucas Seiki Oshiro @ 2025-04-04 21:58 UTC (permalink / raw)
To: Torpey, Bill; +Cc: git@vger•kernel.org
> Shouldn't the recursive clone pick up the HEAD of the submodule branch?
No, because a submodule is a specific reference to a commit of another
repository.
> If it sounds like we don't quite understand what git is doing here, that's a fair statement ;-)
No problem :-D, in fact, the idea of submodules is quite simple: there's
this .gitmodules files where the submodule metadata is stored, and there's
an entry mapping the name of the submodule to its commit inside each
commit of the parent repository.
As a public example we have the Git source code, which has a submodule.
You can clone it with:
git clone https://github.com/git/git.git
I'm working with the current master of that repository, which today is
at the commit 5b97a56. As I said before, this repository has a
submodule called sha1collisiondetection. Supposing that you're inside
the Git repository, if you run:
git rev-parse 5b97a56:sha1collisiondetection
you'll get this hash: 855827c. This is the hash commit of the
submodule at the commit 5b97a56 of the parent repository. Note that I
checked this without touching the submodule itself, as this information
is stored in the parent repository.
You can do that for any commit. For example, if you run for 23e37f8:
git rev-parse 23e37f8:sha1collisiondetection
you'll see that 23e37f8 references another submodule commit. You
can even see the log of submodule reference changes:
git log -- sha1collisiondetection
> but it sounds like git internally stores the commit hash instead?
Yes!
> - 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
Sorry for answering you this out of the order, but it makes
more sense to answer here.
This command will checkout the submodule to the latest commit of
the branch that is in the branch field of the .gitmodules (in
your case, `staging`, or in my case of the Git source code,
`master`).
Going back to my example, let's first initialize the submodule,
which I didn't before:
git submodule update --init --recursive
Then, run your command:
git submodule update --remote --recursive
This will bring the latest commits of the branch `master` of
the submodule. Now, if you run:
git status
you'll see that the submodule has changed. This is because it is
in a commit that is not the one referenced by the HEAD of the
parent repository. Just like a file that was changed and not
committed. And again, just like a file, if you want the
repository to point to that commit from now on you'll need to:
git add sha1collisiondetection
git commit -m "Update the submodule"
> - It sounds like you're suggesting that we need to go into the submodule and manually checkout a specific commit?
Yes, or you can use git submodule update like you were doing,
both work. But keep in mind that it will leave that in a
unstaged state. If you want to keep it, you'll need to commit
that submodule reference change.
In conclusion, think of submodules as dependencies with fixed
versions, where each version change needs to be commited in
the parent repository.
> Thanks again for your help!
You're welcome! I hope that it helps you!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-04-05 11:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-03 14:48 problem w/recursive, submodules? Torpey, Bill
2025-04-04 14:59 ` Lucas Seiki Oshiro
2025-04-04 19:42 ` Torpey, Bill
2025-04-04 21:58 ` Lucas Seiki Oshiro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox