Re: Git core dump checking out main on armv7

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Tue, 18 Jun 2024 19:58:41 UTC :

> Hi Robert,
> 
> On Tue, Jun 18, 2024 at 06:43:44PM +0200, Robert Clausecker wrote:
> > Hi Bob,
> > 
> > I'm not sure what the exact experiment would be. The likely cause is
> > that the meta data is too large to fit into the address space available.
> > You might be able to make things work by doing shallow fetches / pulls,
> > as these don't pull the intermediate commits.
> > 
> I just tried re-cloning a fresh copy of the archive as an experiment:
> 
> # git clone --depth=1 -o freebsd https://git.FreeBSD.org/src.git /usr/src
> Cloning into '/usr/src'...
> remote: Enumerating objects: 104618, done.
> remote: Counting objects: 100% (104618/104618), done.
> remote: Compressing objects: 100% (88910/88910), done.
> remote: Total 104618 (delta 22080), reused 43680 (delta 11795), pack-reused 0
> Receiving objects: 100% (104618/104618), 345.12 MiB | 1.09 MiB/s, done.
> fatal: pack is corrupted (SHA1 mismatch)
> fatal: fetch-pack: invalid index-pack output
> 
> I've been seeing this sort of error repeated over the past weeks.
> It doesn't look like a local problem to me.
. . .

I'm going to quote kevens on discord from another git context:

QUOTE
kevans: once you have git installed anongit via ssh is a lot more reliable, especially for the ports tree
END QUOTE

(Watch out for my unusual directory naming on the left side of the lines:)

If your context allows use of: ssh:// . . .

# grep -rE "(^\[|url = )" /usr/*/.git/config
/usr/official-src/.git/config:[core]
/usr/official-src/.git/config:[remote "freebsd"]
/usr/official-src/.git/config: url = ssh://anongit@git.FreeBSD.org/src.git
/usr/official-src/.git/config:[branch "main"]
/usr/official-src/.git/config:[branch "stable/14"]
/usr/ports/.git/config:[core]
/usr/ports/.git/config:[remote "freebsd"]
/usr/ports/.git/config: url = ssh://anongit@git.FreeBSD.org/ports.git
/usr/ports/.git/config:[branch "main"]


I have historically found such more reliable than use of: https:// . . .

ssh:// . . . can also be used on the command line.


If both ssh:// . . . and https:// . . . fail that likely has
implications different than if just one form does.


===
Mark Millard
marklmi at yahoo.com