Junio C Hamano <gitster@xxxxxxxxx> writes: > Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > >> What is the policy about reference names and their canonicalization? > > The overall policy has been that we care about well-formed input, and > everything else is "undefined", even though as you found out some of them > try to work sensibly. > >> $ git check-ref-format /foo/bar ; echo $? >> 0 >> >> $ git check-ref-format --print /foo/bar >> /foo/bar > > I think these are bogus. Patches welcome. I actually think the former is correct and the latter should strip the leading slash. Essentially what "check-ref-format" (and the underlying check_ref_format() function) validates is if the given user string can be used under $GIT_DIR/refs/ to name a ref, and $GIT_DIR/refs//foo/bar is (because we "tolerate duplicated slashes" cf. comment in the function) the same as $GIT_DIR/refs/foo/bar and is allowed. I do not know what the original motivation behind --print was, but it seems to want to show it canonicalized, so it should strip the leading slash as well. I think what is missing is a unified way to canonicalize the refnames (which led to the inconsistencies you observed), and I strongly suspect that check_ref_format() should learn to return the canonicalized format (if asked by the caller) and the caller should use the canonicalized version after feeding end-user input to it. Then the plumbing "check-ref-format --print" can use it just like any other caller that should be (or already are) using check_ref_format() to validate the end-user input. Yes, such a change will update the overall policy I stated earlier and narrow the scope of "undefined" down a bit, by uniformly codifying that leading and duplicate slashes are removed to be nice to the user. -- 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