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

git fails to checkout SHA1 submodule in SHA256 repo with --depth=1

From
MWMartin Wilck <mwilck@suse.com>
Date
Nov 12, 2025, 12:58 UTC
Message-ID
<c94a929df63f79e49eeae0cd67c1f59f859e3d62.camel@suse.com>
> What did you do before the bug happened? (Steps to reproduce your
issue)

# This is a SHA256 repository with a SHA1 submodule git clone -b next https://src.opensuse.org/mwilck/multipath-tools

cd multipath-tools git submodule init

# Submoudle URL: https://github.com/openSUSE/multipath-tools,  # branch "next git submodule update --depth 1

> What did you expect to happen? (Expected behavior)
Successful checkout of the submodule.
> What happened instead? (Actual behavior)
The following error:

fatal: couldn't find remote ref 37f9a4c9c4658da7f9b2b0345836360d2fb119a0000000000000000000000000 fatal: Fetched in submodule path 'multipath-tools', but it did not contain 37f9a4c9c4658da7f9b2b0345836360d2fb119a0000000000000000000000000. Direct fetching of that commit failed.

> What's different between what you expected and what actually
happened?
It failed.
> Anything else you want to add:
"git submodule update" (without --depth 1) succeeds.

The problem occurs whether or not I use "git submodule set-branch" to select the correct remote branch before running "git submodule update". Neither the "branch" setting in .gitmodules nor in .git/config seems to matter.

The problem seems to be that "git submodule update --depth 1" fetches the remote HEAD only, even if submodule.<name>.branch is set to something different (here: "next"). (In my case, HEAD was not an ancestor of the desired branch ("next"), nor vice-versa).

I found the following workaround to fetch the desired commit:

SUBMODULE=multipath-tools SHA=$(git -C $SUBMODULE ls-remote origin | awk '/refs\/heads\/next/ { print $1; }') git -C $SUBMODULE fetch --depth=1 origin next git -C $SUBMODULE reset --hard $SHA

but that's not the desired solution, because the checkout needs to be scripted. Ultimately I want to run "git clone --recurse-submodules --depth 1", which currently fails as well.

A plain "git clone" of the submodule works as expected:

git clone -b next --depth=1 https://github.com/openSUSE/multipath-tools.git

In a SHA1 repository, all these operations seem to work as one would naïvely expect. (I was using different repositories though, I currently don't have a SHA1 clone of the SHA256 repo I experimented with).

[System Info]
git version:
git version 2.52.0.rc1.458.g3549877.dirty
cpu: x86_64
built from commit: 3549877a16bc196d0d99bc2f8441eedf0102fcc8
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: disabled
libcurl: 8.14.1
OpenSSL: OpenSSL 3.1.4 24 Oct 2023
zlib: 1.2.13
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Linux 6.4.0-150600.23.70-default #1 SMP PREEMPT_DYNAMIC Wed Sep
10 10:54:24 UTC 2025 (225af75) x86_64
compiler info: gnuc: 7.5
libc info: glibc: 2.38
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
Next: Junio C Hamano
Message 1 of 21 in “git fails to checkout SHA1 submodule in SHA256 repo with --depth=1”
  1. Martin WilckNov 12, 2025
  2. Junio C HamanoNov 12, 2025
  3. brian m. carlsonNov 12, 2025
  4. Martin WilckNov 13, 2025
  5. brian m. carlsonNov 13, 2025
  6. Martin WilckNov 13, 2025
  7. Marc BranchaudNov 14, 2025
  8. brian m. carlsonNov 15, 2025
  9. object-file: disallow adding submodules of different hash algobrian m. carlson, Nov 12, 2025
  10. Jeff KingNov 13, 2025
  11. Jeff KingNov 13, 2025
  12. Junio C HamanoNov 13, 2025
  13. brian m. carlsonNov 14, 2025
  14. Jeff KingNov 15, 2025
  15. brian m. carlsonNov 13, 2025
  16. 1/2 object-file: disallow adding submodules of different hash algobrian m. carlson, Nov 15, 2025
  17. 2/2 read-cache: drop submodule check from add_to_cache()brian m. carlson, Nov 15, 2025
  18. Junio C HamanoNov 15, 2025
  19. brian m. carlsonNov 15, 2025
  20. Junio C HamanoNov 15, 2025
  21. Martin WilckNov 17, 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.