Jeff KingI upgraded git on a machine recently, and it created problems for a repo with a bogus character in a ref name. Older versions of git never complained about it. Newer ones, containing your dce4bab ("add_ref(): verify that the refname is formatted correctly") do. That's fine; it's bogus and git _should_ complain about it.
However, recovering from the situation is unnecessarily hard, as basic things like fsck stop working, you can't access the ref via rev-parse, etc. You can reproduce with something like this (in some repo with actual commits):
$ evil=$(printf 'foo\177bar') $ git rev-parse HEAD >".git/refs/tags/$evil"
$ git fsck fatal: Reference has invalid format: 'refs/tags/foo^?bar'
[does not even warn about the real reason for the error] $ git rev-parse --verify "$evil" fatal: Needed a single revision
[does not let you find broken refs] $ git for-each-ref fatal: Reference has invalid format: 'refs/tags/foo^?bar' $ git tag -l fatal: Reference has invalid format: 'refs/tags/foo^?bar'
[no way to rename or delete the bogus tag] $ git tag fixed "$evil" fatal: Failed to resolve 'foo^?bar' as a valid ref.
I seem to recall discussing this format-tightening and trying to be sure that users were left with a way forward for fixing their repos. But I can't find the discussion, and I don't recall any conclusion we came to. So maybe we decided not to worry about it. But I thought I'd mention it as a data point.
-Peff
