>> Sorry but I do not quite get the " and tree-wide" part of the title. I may have some misunderstandings about "tree-wide". Sorry, it will be resolved in the next patch. >>s/trees_and_blobs/non_commits/ will result in a name that is much >>shorter and to the point, I think. Agree and thanks for explanation. Will follow your suggestion in next patch. I don't know why I didn't think of this naming at the time (*headwalls*). In fact, I discovered this problem while contributing packfile-uris related features (thinking about excluding tag objects), and finally said to myself "So you are here" (although it didn't take so much effort), So I decide to make this patch. >>The call to it at the end is meant to sweep anything >>leftover---we will not discover any tag while in the main loop of >>the caller that iterates over commits (as they cannot contain any >>tag in there). Some doubts. I think at the object relationship level: tag> commit> tree> blob The tag is on top because of the annotated tag. So, why the tag is in `revs->pending` to deal? I understand it should be the opposite? A commit should pending to a tag, at least equal. Maybe my understanding is wrong, if so, why this way? Thank you.
