Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > And here's a slight expansion patch on top of the above > > It does: > > - when it actually breaks out due to the "everybody_uninteresting()" > case, it adds the uninteresting commits (both the one it's looking at > now, and the list of pending ones) to the list > > This way, we really list *all* the commits we've looked at > > - Because we now end up listing commits we may not even have been parsed > at all "show_log" and "show_commit" need to protect against commits > that don't have a commit buffer entry. > > That second part is debatable just how it should work. Maybe we shouldn't > show such entries at all (with this patch those entries do get shown, they > just don't get any message shown with them). But I think this is a useful > case. Showing them would probably be useful (definitely for debugging), but I do not think it is useful not to show the buffer contents (i.e. adding without parsing). It _might_ mean that the excess uninteresting ones we take out from "list" can be distinguished from the ones that we did look at (and once thought they were worth keeping), but I do not think it is reliable information. The command line parser may have caused them to be parsed independent from what the revision traversal did. So I think it would make more sense to parse them while we add them to the "newlist", and if we really want to distinguish them from others we would want to mark them separately with another flag bit. Or unparse them when we add them to the "newlist". - 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
