Re: Reference has invalid format: check maybe a bit to harsh?

Junio C Hamano [off-list ref] writes:

I agree that we would want to give users an escape hatch.  That is, if we
can make something like this to work:

    c=$(git rev-parse --force refs/patches/obd_development/blah:_vari...)
    git update-ref refs/patches/obd_development/blah--various-improvements $c

Also we would need to be able to say

    git update-ref -d refs/patches/obd_development/blah:_vari...

to get rid of the offending one.

I think we would be in a good shape.

Having said all that, I think we should in general loosen the checks done
on the reading side a lot more. The "checks" themselves should stay, can
give loud warnings, and even can error out when appropriate, but in an
operation that is necessary to recover from _existing_ breakage (like the
one in this thread, a file with a colon in its name in .git/refs/), the
ability to read and to remove is essential for recovery.

I vaguely recall we had to apply a fix in the same spirit to loosen
reading side after the offending topic was merged to 'master' during this
cycle about $GIT_DIR/config not possibly being a ref getting warned, or
something.

Michael, what do you think?