Yes. I'm taking a slightly weaker approach, which is to say that git
should check not "conventions", but "requirements".
So the reason I made it check HEAD and refs/heads/* is that yes, it's a
convention that they be branches (and thus must point to commit objects),
but it's also something deeper than that: git cit commands actually break
when it's not true.
So I think there is a difference between "convention" and "requirement".
One is how we do things, the other is how things must be done to work.
And yes, conventions have a tendency to become requirements, as people
start depending on them, so it's not a black-and-white or even a static
thing, and it changes over time.
I just suspect that at least right now, if refs/remotes/xyzzy isn't a
commit, nothing actually technically *breaks*, even if it is against the
convention.
For example, would it be wrong to have "remote tags" listed under
refs/remotes/<remotename>/tags? I don't think it necessarily is wrong.
It's not something we support right now, of course, and maybe we never
will, but I don't think it's something that is necessarily conceptually
broken - and maybe some external porcelain would want to do it that way?
So if core git doesn't really care, it shouldn't set the rules. But yes,
the rules clearly have expanded over time, and probably will continue to
do so..
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
