Re: "git shortlog -sn --follow -- <path>" counts all commits to entire repo

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 8, 2017, 17:37 UTC
Message-ID: <xmqqbmmlytv3.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170908074910.reoyb47navgsg6kt@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

> 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.