SZEDER Gábor <szeder.dev@xxxxxxxxx> writes: > So basically the line-level log computes a full tree diff for each > commit-parent pair in step (1) to be used for rename detection in step > (4) in the off chance that an interesting path is missing from the > parent. Good explanation. As we are not supporting swapping of two (or more) files, we only need rename processing when a path we have been inspecting disappears, at which point it is worth spending cycles to see where the path used to be in the parent commit. > [1] Line-level log's rename following is quite similar to 'git log > --follow path', with the notable differences that it does handle > multiple paths at once as well, and that it doesn't show the > commit performing the rename if it's an exact rename. Yeah, it's one of the reasons why "log --follow" is not (yet) a serious "feature" but merely a "checkbox item". > [2] This slowness might not have been apparent initially, because back > when the line-level log feature was introduced rename detection s/introduced/&,/ > was not yet enabled by default; 12da1d1f6f (Implement line-history > search (git log -L), 2013-03-28) and 5404c116aa (diff: activate > diff.renames by default, 2016-02-25). s/\.$/ are about 3 years apart&/ or something like that to make what follows the semicolon a full sentence?
