Re: bootstrap fails with SHA256 default object format

On Sun, 09 Aug 2026 at 15:29:34 +0200, Bruno Haible wrote:
> Him

Him

> Seth McDonald wrote:
> > I believe I've found a bug in Gnulib's bootstrap functionality.  When
> > attempting to ./bootstrap Libntlm 1.8 (from [0]), I ran into this error:
[...]
> > Usually this shouldn't occur, since I believe git-clone sets the object
> > format automatically to the same as upstream.  But after grepping
> > Libntlm's bootstrap scripts, I found that it instead invokes git-init
> > and manually adds the upstream with git-remote.  From
> > bootstrap-funclib.sh, lines 527-529 (see [1]):
> > 
> > 	git -C "$gnulib_path" init
> > 	git -C "$gnulib_path" remote add origin \
> > 	    ${GNULIB_URL:-$default_gnulib_url}
> 
> Yes. We do this in order to save network bandwidth.

I see.  FWIW, I believe git-clone can download only a particular
revision <rev> with the `--depth=1 --revision=<rev>` options.  Though
--revision is a recent addition, so I understand if it can't be used
here.

[...]
> > As such, the bug can be fixed by appending --object-format=sha1 to the
> > git-init command, which forces git to initialise the repo with a SHA1
> > object format regardless of the global default.
> 
> We can't do this, because the option --object-format=sha1 was only introduced
> in git version 2.27 (2020), which is too new. We can't assume all users of
> Gnulib have a git version that is this new.
> 
> > I've tested this with
> > the same Libntlm repository and it appears to work.
> 
> Instead I'm applying the patch below. Can you please test whether it works
> for you?

I can confirm it works.  Thanks for the fix!

Take care,
	Seth McDonald.

-- 
E9D1 26A5 F0D4 9DF7 792B  C2E2 B4BF 4530 D39B 2D51