Junio C Hamano <gitster@xxxxxxxxx> writes: > Patrick Steinhardt <ps@xxxxxx> writes: > >> So any reference that contains additional data is not a proper ref and >> thus should be warned about from my point of view. No Git tooling should >> write them, so if something does it's a red flag to me. > > If you find such a file in $GIT_DIR/refs/ hierarchy, because our > consumer side has been looser than necessary forever, and we never > have written such a file ourselves, it is a sign that a third-party > tool wrote it, and that the third-party tool used our reader > implementation as the specification. That is why I am hesitant to > retroactively tighten the rules like this patch does. I forgot to add my recommended course of action, without which a review is worth much less X-<. I am OK if we tightened the rules retroactively, as long as it starts as a probing check (i.e. "info: we found an unusual thing in the wild. Please report this to us so that we can ask you for more details like how such a ref that would violate a rule that was retroactively tightened got there", not "error: malformed ref"). Thanks.
