git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: git@vger.kernel.org
Cc: Adrian Schroeter <adrian@suse.com>
Subject: git fails to checkout SHA1 submodule in SHA256 repo with --depth=1
Date: Wed, 12 Nov 2025 13:58:46 +0100	[thread overview]
Message-ID: <c94a929df63f79e49eeae0cd67c1f59f859e3d62.camel@suse.com> (raw)

> 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]


             reply	other threads:[~2025-11-12 13:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-12 12:58 Martin Wilck [this message]
2025-11-12 16:32 ` git fails to checkout SHA1 submodule in SHA256 repo with --depth=1 Junio C Hamano
2025-11-12 23:37   ` brian m. carlson
2025-11-13 10:15     ` Martin Wilck
2025-11-13 22:51       ` brian m. carlson
2025-11-13 22:57         ` Martin Wilck
2025-11-14 22:55       ` Marc Branchaud
2025-11-15 20:14         ` brian m. carlson
2025-11-12 23:54 ` [PATCH] object-file: disallow adding submodules of different hash algo brian m. carlson
2025-11-13  3:26   ` Jeff King
2025-11-13  3:56     ` Jeff King
2025-11-13 16:29       ` Junio C Hamano
2025-11-14 23:26         ` brian m. carlson
2025-11-15  1:53           ` Jeff King
2025-11-13 23:15     ` brian m. carlson
2025-11-15  0:58   ` [PATCH v2 1/2] " brian m. carlson
2025-11-15  0:58     ` [PATCH v2 2/2] read-cache: drop submodule check from add_to_cache() brian m. carlson
2025-11-15 19:57       ` Junio C Hamano
2025-11-15 20:06         ` brian m. carlson
2025-11-15 19:53     ` [PATCH v2 1/2] object-file: disallow adding submodules of different hash algo Junio C Hamano
2025-11-17  8:53     ` Martin Wilck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c94a929df63f79e49eeae0cd67c1f59f859e3d62.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=adrian@suse.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).