Thomas Hurst <tom@xxxxxx> writes: > I've noticed a series of about 20 commits in the HardenedBSD repository > fairly reliably produce garbage names from git name-rev - usually > fragments of another commit, sometimes unprintable nonsense. Sometimes > it works just fine... > > Here's a quick demo showing how to reproduce the problem: > > % uname -mrs > FreeBSD 13.0-RELEASE-p11 amd64 > % git --version > git version 2.35.2 > % git clone --bare --mirror https://github.com/HardenedBSD/hardenedBSD.git > % cd hardenedBSD.git > % git rev-list --branches=\* | > git name-rev --stdin --refs=heads/\* | > egrep -v '^[0-9a-f]{40}( \([a-zA-Z0-9_/.^~-]+\))?$' > 3eb67b534cab6a78b44b13e4323fd60353003089 (y: marcel > MFC after: 3 days > Relnotes: yes > Sponsored by: ScaleEngine Inc. > Differential Revision: https://reviews.freebsd.org/D3065 > ~3) > 3ac660fc0c6eb0f876972e7e415c89f1ebed1939 (y: marcel > ... > Passing these commits into name-rev as arguments finds them under > hardened/current/relro~199^2 > > git fsck --full does not reveal or fix anything, and the problem also > persists with a build from source from the next branch. > > I was unable to reproduce on an Ubuntu machine with 2.32.0, so I used > that as a starting point for bisection and landed here: > > 3656f842789d25d75da41c6c029470052a573b54 > name-rev: prefer shorter names over following merges commit 3656f842789d25d75da41c6c029470052a573b54 Author: Elijah Newren <newren@xxxxxxxxx> Hmph, Elijah, does this ring a bell? Thanks.
