Junio C Hamano <gitster@xxxxxxxxx> 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?
--
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