I 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html