Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > How to take care of the recovery use case is another question. FWIW I > also would prefer if "git update-ref -d" or "git branch -D" could be > used to delete corrupt refs instead of having to use fsck (since a > fsck run can take a while), but that's a question for a later series. Good thinking. > In an ideal world, the low-level functions would allow *reading* and > *deleting* poorly named refs (even without any special flag) but not > creating them. Is that doable? The main complication I can see is > iteration: would iteration skip poorly named refs and warn, or would > something more complicated be needed? I somehow thought that was what we have always designed for, which DO_FOR_EACH_INCLUDE_BROKEN was a part of. -- 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