Junio C Hamano <gits...@pobox.com> writes: > Alex Bennée <kernel-hac...@bennee.com> writes: > >> Why is git attempting to parse a commit not on the DAG for the branch >> I'm attempting to describe? > > I think that is because you need to parse the objects at the tip of > refs to see if they are on the DAG in the first place. > > If there weren't any annotated tag, conceivably you could do without > parsing these objects. You would: > > - First read the refs without parsing anything to learn the object > name of the tips of refs; > > - Traverse the DAG, starting from the commit and notice when you > see commits that are at the tips of refs you learned in the first > step, arranging to stop when you found the "closest" tip. > > But with annotated tags (and "git describe" is designed to be > primarily used with them; you would need "--tags" option to make it > notice unannotated tags), the object name you see sitting at the tip > will never appear during the DAG traversal. You will only see > commits from the latter, so you would need to parse the tips to > learn what commits they refer to. > > And of course, "then parse only annotated tags, without parsing > commits" would not work, because you wouldn't know what the object > is without looking at it ;-)
Having said all that, with changes by Peff and Michael Haggerty around f85354b5c7b8 (pack_one_ref(): use function peel_entry(), 2013-04-22), recent Git does not "parse" as many refs as it used to, only to figure out what commit an annotated tag points at when your refs are packed, so we may be a lot closer to the optimum than I hinted by the above description. -- 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
