Jeff King <peff@xxxxxxxx> writes: > Yeah. It depends on exactly how such a fix is made. I think one > improvement would be to actually bump --follow handling into the > limit_list() stage, so that we properly handle history simplification > over followed paths. In which case get_revision() would just never > return the uninteresting commits, and the current shortlog code would > Just Work. > > That said, I don't think we can go wrong by making shortlog's traversal > more like log's. Any changes we make to --follow will be aimed at and > tested with git-log, so the more code they share the more likely it is > that shortlog won't bitrot. Both true. Using log-tree traversal machinery instead of just get_revision() would probably mean we would slow it down quite a bit unless we are careful, but at the same time, things like "git shortlog -G<string>" would suddenly start working, so this is not just helping the "--follow" hack.
