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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 31, 2011, 20:19 UTC
Message-ID: <7vpqhcq5h2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vty6pos20.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 5 quoted lines

> 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?