On Tue, Jul 15, 2014 at 11:34 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. I think that include broken only handles the case where the ref itself is bad, not when the refname is bad. I.e. it affects cases where the sha1 does not exist or the symref points to nowhere. -- 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