On Mon, May 12, 2025 at 04:39:43PM +0200, Patrick Steinhardt wrote: > > And header is introduced in 694b7a1999 (repack_without_ref(): write peeled > > refs in the rewritten file, 2013-04-22). At this commit, we would always > > write the header into the "packed-refs" file. > > So what happened before this commit? Would we end up writing a > completely empty file? Yeah, prior to that if you delete the final entry, you'd get an empty file. Reproducible with: # you can use modern git for this part git init git commit --allow-empty -m foo git checkout --detach git pack-refs --all # old git writes empty file during deletion git.v1.8.4 branch -D main ls -l .git/packed-refs Going back even further, we'd also write an empty file via pack-refs. With git v1.4.4, doing "git init && git pack-refs" will get you an empty file. I didn't bisect completely, but presumably that changed in f4204ab9f6 (Store peeled refs in packed-refs (take 2)., 2006-11-21). > I think it depends. If we can prove that Git (and other, third-party > implementations thereof) wouldn't have ever written such "packed-refs" > files then we should start warning now already, even if we accept such > files at runtime. Otherwise, if there were versions of Git that could > have ended up writing such files I agree that we have to accept this for > now. So we definitely did write those files. Those are pretty old versions of Git, but something we should continue to support. It may be useful for fsck to detect this, though, even if the default message severity is set to "info" or even "ignore. That would allow people who know they are using modern Git to increase it themselves (I don't expect normal users to do this, but it would probably be useful for forges which run automated "fsck" across a lot of repos). And then the backwards-incompatible Git 3.0 thing would just be tweaking the severity of the config (and in the meantime, it would help flush out any unexpected instances people run into). -Peff
