On Wed, 16 Jan 2008, Junio C Hamano wrote: > > If we take that "plumbing knows much more about Porcelain > convention" shift-of-paradigm all the way, refs/remotes/ would > contain what are copied from refs/heads/ elsewhere, so checking > would have been correct. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
