On 8/18/2019 2:27 PM, SZEDER Gábor wrote: > Line-level log performs a preprocessing step in > prepare_revision_walk(), during which it filters and rewrites history > to keep only commits modifying the given line range. This > preprocessing causes significant delay before the first commit is > shown, wastes CPU time when the user asks only for a few commits, and > does parent rewriting with no way to turn it off. > > This patch series addresses these issues by integrating line-level log > filtering into the revision walking machinery and making it work > together with generation number-based topo-ordering (though for now > only in the case when the user doesn't explicitly asks for parent > rewriting, which is probably the common case). > > The first two patches are quite straightforward (and arguably somewhat > unrelated), but the rest deals with history traversal and parent > rewriting, which I don't usually do, hence the RFC. > > > SZEDER Gábor (5): > completion: offer '--(no-)patch' among 'git log' options > line-log: remove unused fields from 'struct line_log_data' > t4211-line-log: add tests for parent oids > line-log: more responsive, incremental 'git log -L' > line-log: try to use generation number-based topo-ordering Hi Szeder, I was taking inventory of our issues especially around history now that the changed-path Bloom filters are close to wrapping up. What's the status on this RFC? Looking at it now, I understand the situation better and could help review a bit more than before. Do you have more context as to the situation on this series? Thanks, -Stolee
