From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Mon, 19 Aug 2019 12:34:31 GMT
Subject: Re: [RFC PATCH 4/5] line-log: more responsive, incremental 'git log -L'
Message-ID: <20190819123431.GT20404@szeder.dev>
In-Reply-To: <20190818182801.7580-5-szeder.dev@gmail.com>

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/