On Sun, Aug 18, 2019 at 08:28:00PM +0200, SZEDER Gábor wrote: > The current line-level log implementation performs a preprocessing > step in prepare_revision_walk(), during which the line_log_filter() > function filters and rewrites history to keep only commits modifying > the given line range. This preprocessing affects both responsiveness > and correctness: > > - Git doesn't produce any output during this preprocessing step. > Checking whether a commit modified the given line range is > somewhat expensive, so depending on the size of the given revision > range this preprocessing can result in a significant delay before > the first commit is shown. > > - Limiting the number of displayed commits (e.g. 'git log -3 -L...') > doesn't limit the amount of work during preprocessing, because > that limit is applied during history traversal. Alas, by that > point this expensive preprocessing step has already churned > through the whole revision range to find all commits modifying the > revision range, even though only a few of them need to be shown. s/revision range/line range/
