On 2013-06-19 13:14, Junio C Hamano wrote: > <object-type>-ish does not have anything to do with a ref. Even > when an object is dangling in your object store without being > reachable from any of your refs, it keeps its own "ish"-ness.
Ah, so your personal definition of "ref" matches my personal definition of "ref", and this definition doesn't match gitglossary(7). :) > > "ish"-ness is a property of the object itself. > > * A commit object has a single top-level tree, and when a command > wants a tree object, you can often pass it a commit (historically > some commands were more strict and refused to work on a commit > when they wanted a tree). In other words, a commit can be used > in place for a tree. A commit object is a tree-ish. > > * A tag object, when it points (recursively) at a commit object, > can often be used in place for a commit object. Such a tag > object is a commit-ish. > > * A tag object, when it points (recursively) at a tree object, can > often be used in place for a tree object. Such a tag object is a > tree-ish. Note that such a tag object cannot be a commit-ish. I agree with all of this; the issue is the definition of "ref" in gitglossary(7). That definition should be fixed. In the meantime, I'll rework the patch series to avoid using the word "ref" when defining committish and tree-ish. -Richard -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
