ref-format checking regression

[Jeff King <peff@peff.net>]

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