{"thread":{"id":"51666","subject":"[RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","startedAt":"2019-08-18T18:28:13Z","lastAt":"2020-04-24T09:02:51Z","messageCount":17,"participants":["SZEDER Gábor","Derrick Stolee"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"380624","messageId":"20190818182801.7580-1-szeder.dev@gmail.com","threadId":"51666","inReplyTo":null,"subject":"[RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-18T18:27:56Z","receivedAt":"2019-08-18T18:28:13Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Line-level log performs a preprocessing step in\nprepare_revision_walk(), during which it filters and rewrites history\nto keep only commits modifying the given line range.  This\npreprocessing causes significant delay before the first commit is\nshown, wastes CPU time when the user asks only for a few commits, and\ndoes parent rewriting with no way to turn it off.\n\nThis patch series addresses these issues by integrating line-level log\nfiltering into the revision walking machinery and making it work\ntogether with generation number-based topo-ordering (though for now\nonly in the case when the user doesn't explicitly asks for parent\nrewriting, which is probably the common case).\n\nThe first two patches are quite straightforward (and arguably somewhat\nunrelated), but the rest deals with history traversal and parent\nrewriting, which I don't usually do, hence the RFC.\n\n\nSZEDER Gábor (5):\n  completion: offer '--(no-)patch' among 'git log' options\n  line-log: remove unused fields from 'struct line_log_data'\n  t4211-line-log: add tests for parent oids\n  line-log: more responsive, incremental 'git log -L'\n  line-log: try to use generation number-based topo-ordering\n\n contrib/completion/git-completion.bash |  1 +\n line-log.c                             |  4 +-\n line-log.h                             |  5 +-\n revision.c                             | 38 +++++++++++---\n t/t4211-line-log.sh                    | 68 ++++++++++++++++++++++++++\n 5 files changed, 105 insertions(+), 11 deletions(-)\n\n-- \n2.23.0.349.g73f10e387d\n\n"},{"id":"380625","messageId":"20190818182801.7580-2-szeder.dev@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-1-szeder.dev@gmail.com","subject":"[RFC PATCH 1/5] completion: offer '--(no-)patch' among 'git log' options","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-18T18:27:57Z","receivedAt":"2019-08-18T18:28:14Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>\n---\n contrib/completion/git-completion.bash | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex e087c4bf00..57f984340e 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1804,6 +1804,7 @@ _git_log ()\n \t\t\t$merge\n \t\t\t$__git_diff_common_options\n \t\t\t--pickaxe-all --pickaxe-regex\n+\t\t\t--patch --no-patch\n \t\t\t\"\n \t\treturn\n \t\t;;\n-- \n2.23.0.349.g73f10e387d\n\n"},{"id":"380626","messageId":"20190818182801.7580-3-szeder.dev@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-1-szeder.dev@gmail.com","subject":"[RFC PATCH 2/5] line-log: remove unused fields from 'struct line_log_data'","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-18T18:27:58Z","receivedAt":"2019-08-18T18:28:16Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Remove the unused fields 'status', 'arg_alloc', 'arg_nr' and 'args'\nfrom 'struct line_log_data'.  They were already part of the struct\nwhen it was introduced in commit 12da1d1f6 (Implement line-history\nsearch (git log -L), 2013-03-28), but as far as I can tell none of\nthem have ever been actually used.\n\nSigned-off-by: SZEDER Gábor <szeder.dev@gmail.com>\n---\n line-log.h | 3 ---\n 1 file changed, 3 deletions(-)\n\ndiff --git a/line-log.h b/line-log.h\nindex 8ee7a2bd4a..882c5055bb 100644\n--- a/line-log.h\n+++ b/line-log.h\n@@ -46,10 +46,7 @@ void sort_and_merge_range_set(struct range_set *);\n struct line_log_data {\n \tstruct line_log_data *next;\n \tchar *path;\n-\tchar status;\n \tstruct range_set ranges;\n-\tint arg_alloc, arg_nr;\n-\tconst char **args;\n \tstruct diff_filepair *pair;\n \tstruct diff_ranges diff;\n };\n-- \n2.23.0.349.g73f10e387d\n\n"},{"id":"380627","messageId":"20190818182801.7580-4-szeder.dev@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-1-szeder.dev@gmail.com","subject":"[RFC PATCH 3/5] t4211-line-log: add tests for parent oids","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-18T18:27:59Z","receivedAt":"2019-08-18T18:28:18Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"None of the tests in 't4211-line-log.sh' really check which parent\nobject IDs are shown in the output, either implicitly as part of\n\"Merge: ...\" lines [1] or explicitly via the '%p' or '%P' format\nspecifiers in a custom pretty format.\n\nAdd two tests to 't4211-line-log.sh' to check which parent object IDs\nare shown, one without and one with explicitly requested parent\nrewriting, IOW without and with the '--parents' option.\n\nThe test without '--parents' is marked as failing, because without\nthat option parent rewriting should not be performed, and thus the\nparent object ID should be that of the immediate parent, just like in\ncase of a pathspec-limited history traversal without parent rewriting.\nThe current line-level log implementation, however, performs parent\nrewriting unconditionally and without a possibility to turn it off,\nand, consequently, it shows the object ID of the most recent ancestor\nthat modified the given line range.\n\nIn both of these new tests we only really care about the object IDs of\nthe listed commits and their parents, but not the diffs of the line\nranges; the diffs have already been thoroughly checked in the previous\ntests.\n\n[1] While one of the tests ('-M -L ':f:b.c' parallel-change') does\n    list a merge commit, both of its parents happen to modify the\n    given line range and are listed as well, so the implications of\n    parent rewriting remained hidden and untested.\n\nSigned-off-by: SZEDER Gábor <szeder.dev@gmail.com>\n---\n t/t4211-line-log.sh | 68 +++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 68 insertions(+)\n\ndiff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh\nindex 1db7bd0f59..c378a453de 100755\n--- a/t/t4211-line-log.sh\n+++ b/t/t4211-line-log.sh\n@@ -132,4 +132,72 @@ test_expect_success '--raw is forbidden' '\n \ttest_must_fail git log -L1,24:b.c --raw\n '\n \n+# Create the following linear history, where each commit does what its\n+# subject line promises:\n+#\n+#   * 66c6410 Modify func2() in file.c\n+#   * 50834e5 Modify other-file\n+#   * fe5851c Modify func1() in file.c\n+#   * 8c7c7dd Add other-file\n+#   * d5f4417 Add func1() and func2() in file.c\n+test_expect_success 'setup for checking line-log and parent oids' '\n+\tgit checkout --orphan parent-oids &&\n+\tgit reset --hard &&\n+\n+\tcat >file.c <<-\\EOF &&\n+\tint func1()\n+\t{\n+\t    return F1;\n+\t}\n+\n+\tint func2()\n+\t{\n+\t    return F2;\n+\t}\n+\tEOF\n+\tgit add file.c &&\n+\ttest_tick &&\n+\tgit commit -m \"Add func1() and func2() in file.c\" &&\n+\n+\techo 1 >other-file &&\n+\tgit add other-file &&\n+\tgit commit -m \"Add other-file\" &&\n+\n+\tsed -e \"s/F1/F1 + 1/\" file.c >tmp &&\n+\tmv tmp file.c &&\n+\tgit commit -a -m \"Modify func1() in file.c\" &&\n+\n+\techo 2 >other-file &&\n+\tgit commit -a -m \"Modify other-file\" &&\n+\n+\tsed -e \"s/F2/F2 + 2/\" file.c >tmp &&\n+\tmv tmp file.c &&\n+\tgit commit -a -m \"Modify func2() in file.c\" &&\n+\n+\thead_oid=$(git rev-parse --short HEAD) &&\n+\tprev_oid=$(git rev-parse --short HEAD^) &&\n+\troot_oid=$(git rev-parse --short HEAD~4)\n+'\n+\n+# Parent oid should be from immediate parent.\n+test_expect_failure 'parent oids without parent rewriting' '\n+\tcat >expect <<-EOF &&\n+\t$head_oid $prev_oid Modify func2() in file.c\n+\t$root_oid  Add func1() and func2() in file.c\n+\tEOF\n+\tgit log --format=\"%h %p %s\" --no-patch -L:func2:file.c >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+# Parent oid should be from the most recent ancestor touching func2(),\n+# i.e. in this case from the root commit.\n+test_expect_success 'parent oids with parent rewriting' '\n+\tcat >expect <<-EOF &&\n+\t$head_oid $root_oid Modify func2() in file.c\n+\t$root_oid  Add func1() and func2() in file.c\n+\tEOF\n+\tgit log --format=\"%h %p %s\" --no-patch -L:func2:file.c --parents >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n-- \n2.23.0.349.g73f10e387d\n\n"},{"id":"380629","messageId":"20190818182801.7580-5-szeder.dev@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-1-szeder.dev@gmail.com","subject":"[RFC PATCH 4/5] line-log: more responsive, incremental 'git log -L'","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-18T18:28:00Z","receivedAt":"2019-08-18T18:28:20Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"The current line-level log implementation performs a preprocessing\nstep in prepare_revision_walk(), during which the line_log_filter()\nfunction filters and rewrites history to keep only commits modifying\nthe given line range.  This preprocessing affects both responsiveness\nand correctness:\n\n  - Git doesn't produce any output during this preprocessing step.\n    Checking whether a commit modified the given line range is\n    somewhat expensive, so depending on the size of the given revision\n    range this preprocessing can result in a significant delay before\n    the first commit is shown.\n\n  - Limiting the number of displayed commits (e.g. 'git log -3 -L...')\n    doesn't limit the amount of work during preprocessing, because\n    that limit is applied during history traversal.  Alas, by that\n    point this expensive preprocessing step has already churned\n    through the whole revision range to find all commits modifying the\n    revision range, even though only a few of them need to be shown.\n\n  - It rewrites parents, with no way to turn it off.  Without the user\n    explicitly requesting parent rewriting any parent object ID shown\n    should be that of the immediate parent, just like in case of a\n    pathspec-limited history traversal without parent rewriting.\n\n    However, after that preprocessing step rewrote history, the\n    subsequent \"regular\" history traversal (i.e. get_revision() in a\n    loop) only sees commits modifying the given line range.\n    Consequently, it can only show the object ID of the last ancestor\n    that modified the given line range (which might happen to be the\n    immediate parent, but many-many times it isn't).\n\nThis patch addresses both the correctness and, at least for the common\ncase, the responsiveness issues by integrating line-level log\nfiltering into the regular revision walking machinery:\n\n  - Make process_ranges_arbitrary_commit(), the static function in\n    'line-log.c' deciding whether a commit modifies the given line\n    range, public by removing the static keyword and adding the\n    'line_log_' prefix, so it can be called from other parts of the\n    revision walking machinery.\n\n  - If the user didn't explicitly ask for parent rewriting (which, I\n    believe, is the most common case):\n\n    - Call this now-public function during regular history traversal,\n      namely from get_commit_action() to ignore any commits not\n      modifying the given line range.\n\n      Note that while this check is relatively expensive, it must be\n      performed before other, much cheaper conditions, because the\n      tracked line range must be adjusted even when the commit will\n      end up being ignored by other conditions.\n\n    - Skip the line_log_filter() call, i.e. the expensive\n      preprocessing step, in prepare_revision_walk(), because, thanks\n      to the above points, the revision walking machinery is now able\n      to filter out commits not modifying the given line range while\n      traversing history.\n\n      This way the regular history traversal sees the unmodified\n      history, and is therefore able to print the object ids of the\n      immediate parents of the listed commits.  The eliminated\n      preprocessing step can greatly reduce the delay before the first\n      commit is shown, see the numbers below.\n\n  - However, if the user did explicitly ask for parent rewriting via\n    '--parents' or a similar option, then stick with the current\n    implementation for now, i.e. perform that expensive filtering and\n    history rewriting in the preprocessing step just like we did\n    before, leaving the initial delay as long as it was.\n\nI tried to integrate line-level log filtering with parent rewriting\ninto the regular history traversal, but, unfortunately, several\nsubtleties resisted... :)  Maybe someday we'll figure out how to do\nthat, but until then at least the simple and common (i.e. without\nparent rewriting) 'git log -L:func:file' commands can benefit from the\nreduced delay.\n\nThis change makes the failing 'parent oids without parent rewriting'\ntest in 't4211-line-log.sh' succeed.\n\nThe reduced delay is most noticable when there's a commit modifying\nthe line range near the tip of a large-ish revision range:\n\n  # no parent rewriting requested, no commit-graph present\n  $ time git --no-pager log -L:read_alternate_refs:sha1-file.c -1 v2.23.0\n\n  Before:\n\n    real    0m9.570s\n    user    0m9.494s\n    sys     0m0.076s\n\n  After:\n\n    real    0m0.718s\n    user    0m0.674s\n    sys     0m0.044s\n\nA significant part of the remaining delay is spent reading and parsing\ncommit objects in limit_list().  With the help of the commit-graph we\ncan eliminate most of that reading and parsing overhead, so here are\nthe timing results of the same command as above, but this time using\nthe commit-graph:\n\n  Before:\n\n    real    0m8.874s\n    user    0m8.816s\n    sys     0m0.057s\n\n  After:\n\n    real    0m0.107s\n    user    0m0.091s\n    sys     0m0.013s\n\nThe next patch will further reduce the remaining delay.\n\nTo be clear: this patch doesn't actually optimize the line-level log,\nbut merely moves most of the work from the preprocessing step to the\nhistory travelsal, so the commits modifying the line range can be\nshown as soon as they are processed, and the traversal can be\nterminated as soon as the given number of commits are shown.\nConsequently, listing the full history of a line range, potentially\nall the way to the root commit, will take the same time as before (but\nat least the user might start reading the output earlier).\nFurthermore, if the most recent commit modifying the line range is far\naway from the starting revision, then that initial delay will still be\nsignificant.\n\nSigned-off-by: SZEDER Gábor <szeder.dev@gmail.com>\n---\n\nNotes:\n    Regarding that \"most common case\": I know, I know, one should not\n    extrapolate only from his own usage patterns...  But FWIW, I've been\n    using various versions of this patch for over two years now, and never\n    missed the rewritten parents.  And just pulled a couple of years worth\n    of ~/.bash_history files from backups, and there was not a single\n    occasion where I used line-level log with parent rewriting (apart from\n    testing these changes).\n\n line-log.c          |  4 ++--\n line-log.h          |  2 ++\n revision.c          | 27 ++++++++++++++++++++++++++-\n t/t4211-line-log.sh |  2 +-\n 4 files changed, 31 insertions(+), 4 deletions(-)\n\ndiff --git a/line-log.c b/line-log.c\nindex 3aff1849e7..772ab57d52 100644\n--- a/line-log.c\n+++ b/line-log.c\n@@ -1194,7 +1194,7 @@ static int process_ranges_merge_commit(struct rev_info *rev, struct commit *comm\n \t/* NEEDSWORK leaking like a sieve */\n }\n \n-static int process_ranges_arbitrary_commit(struct rev_info *rev, struct commit *commit)\n+int line_log_process_ranges_arbitrary_commit(struct rev_info *rev, struct commit *commit)\n {\n \tstruct line_log_data *range = lookup_line_range(rev, commit);\n \tint changed = 0;\n@@ -1237,7 +1237,7 @@ int line_log_filter(struct rev_info *rev)\n \twhile (list) {\n \t\tstruct commit_list *to_free = NULL;\n \t\tcommit = list->item;\n-\t\tif (process_ranges_arbitrary_commit(rev, commit)) {\n+\t\tif (line_log_process_ranges_arbitrary_commit(rev, commit)) {\n \t\t\t*pp = list;\n \t\t\tpp = &list->next;\n \t\t} else\ndiff --git a/line-log.h b/line-log.h\nindex 882c5055bb..82ae8d98a4 100644\n--- a/line-log.h\n+++ b/line-log.h\n@@ -54,6 +54,8 @@ struct line_log_data {\n void line_log_init(struct rev_info *rev, const char *prefix, struct string_list *args);\n \n int line_log_filter(struct rev_info *rev);\n+int line_log_process_ranges_arbitrary_commit(struct rev_info *rev,\n+\t\t\t\t\t\t    struct commit *commit);\n \n int line_log_print(struct rev_info *rev, struct commit *commit);\n \ndiff --git a/revision.c b/revision.c\nindex 07412297f0..6bdfcb38cd 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -36,6 +36,8 @@ static const char *term_good;\n \n implement_shared_commit_slab(revision_sources, char *);\n \n+static inline int want_ancestry(const struct rev_info *revs);\n+\n void show_object_with_name(FILE *out, struct object *obj, const char *name)\n {\n \tconst char *p;\n@@ -3359,7 +3361,14 @@ int prepare_revision_walk(struct rev_info *revs)\n \t\t\tsort_in_topological_order(&revs->commits, revs->sort_order);\n \t} else if (revs->topo_order)\n \t\tinit_topo_walk(revs);\n-\tif (revs->line_level_traverse)\n+\tif (revs->line_level_traverse && want_ancestry(revs))\n+\t\t/*\n+\t\t * At the moment we can only do line-level log with parent\n+\t\t * rewriting by performing this expensive pre-filtering step.\n+\t\t * If parent rewriting is not requested, then we rather\n+\t\t * perform the line-level log filtering during the regular\n+\t\t * history traversal.\n+\t\t */\n \t\tline_log_filter(revs);\n \tif (revs->simplify_merges)\n \t\tsimplify_merges(revs);\n@@ -3569,6 +3578,22 @@ enum commit_action get_commit_action(struct rev_info *revs, struct commit *commi\n \t\treturn commit_ignore;\n \tif (commit->object.flags & UNINTERESTING)\n \t\treturn commit_ignore;\n+\tif (revs->line_level_traverse && !want_ancestry(revs)) {\n+\t\t/*\n+\t\t * In case of line-level log with parent rewriting\n+\t\t * prepare_revision_walk() already took care of all line-level\n+\t\t * log filtering, and there is nothing left to do here.\n+\t\t *\n+\t\t * If parent rewriting was not requested, then this is the\n+\t\t * place to perform the line-level log filtering.  Notably,\n+\t\t * this check, though expensive, must come before the other,\n+\t\t * cheaper filtering conditions, because the tracked line\n+\t\t * ranges must be adjusted even when the commit will end up\n+\t\t * being ignored based on other conditions.\n+\t\t */\n+\t\tif (!line_log_process_ranges_arbitrary_commit(revs, commit))\n+\t\t\treturn commit_ignore;\n+\t}\n \tif (revs->min_age != -1 &&\n \t    comparison_date(revs, commit) > revs->min_age)\n \t\t\treturn commit_ignore;\ndiff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh\nindex c378a453de..8096208abb 100755\n--- a/t/t4211-line-log.sh\n+++ b/t/t4211-line-log.sh\n@@ -180,7 +180,7 @@ test_expect_success 'setup for checking line-log and parent oids' '\n '\n \n # Parent oid should be from immediate parent.\n-test_expect_failure 'parent oids without parent rewriting' '\n+test_expect_success 'parent oids without parent rewriting' '\n \tcat >expect <<-EOF &&\n \t$head_oid $prev_oid Modify func2() in file.c\n \t$root_oid  Add func1() and func2() in file.c\n-- \n2.23.0.349.g73f10e387d\n\n"},{"id":"380628","messageId":"20190818182801.7580-6-szeder.dev@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-1-szeder.dev@gmail.com","subject":"[RFC PATCH 5/5] line-log: try to use generation number-based topo-ordering","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-18T18:28:01Z","receivedAt":"2019-08-18T18:28:21Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"The previous patch made it possible to perform line-level filtering\nduring history traversal instead of in an expensive preprocessing\nstep, but it still requires some simpler preprocessing steps, notably\ntopo-ordering.  However, nowadays we have commit-graphs storing\ngeneration numbers, which make it possible to incrementally traverse\nthe history in topological order, without the preparatory limit_list()\nand sort_in_topological_order() steps; see b45424181e (revision.c:\ngeneration-based topo-order algorithm, 2018-11-01).\n\nThis patch combines the two, so we can do both the topo-ordering and\nthe line-level filtering during history traversal, eliminating even\nthose simpler preprocessing steps, and thus further reducing the delay\nbefore showing the first commit modifying the given line range.\n\nThe 'revs->limited' flag plays the central role in this, because, due\nto limitations of the current implementation, the generation\nnumber-based topo-ordering is only enabled when this flag remains\nunset.  Line-level log, however, always sets this flag in\nsetup_revisions() ever since the feature was introduced in 12da1d1f6f\n(Implement line-history search (git log -L), 2013-03-28).  The reason\nfor setting 'limited' is unclear, though, because the line-level log\nitself doesn't directly depend on it, and it doesn't affect how the\nlimit_list() function limits the revision range.  However, there is an\nindirect dependency: the line-level log requires topo-ordering, and\nthe \"traditional\" sort_in_topological_order() requires an already\nlimited commit list since e6c3505b44 (Make sure we generate the whole\ncommit list before trying to sort it topologically, 2005-07-06).  The\nnew, generation numbers-based topo-ordering doesn't require a limited\ncommit list anymore.\n\nSo don't set 'revs->limited' for line-level log, unless it is really\nnecessary, namely:\n\n  - The user explicitly requested parent rewriting, because that is\n    still done in the line_log_filter() preprocessing step (see\n    previous patch), which requires sort_in_topological_order() and in\n    turn limit_list() as well.\n\n  - A commit-graph file is not available or it doesn't yet contain\n    generation numbers.  In these cases we had to fall back on\n    sort_in_topological_order() and in turn limit_list().  The\n    existing condition with generation_numbers_enabled() has already\n    ensured that the 'limited' flag is set in these cases; this patch\n    just makes sure that the line-level log sets 'revs->topo_order'\n    before that condition.\n\nWhile the reduced delay before showing the first commit is measurable\nin git.git, it takes a bigger repository to make it clearly noticable.\nIn both cases below the line ranges were chosen so that they were\nmodified rather close to the starting revisions, so the effect of this\nchange is most noticable.\n\n  # git.git\n  $ time git --no-pager log -L:read_alternate_refs:sha1-file.c -1 v2.23.0\n\n  Before:\n\n    real    0m0.107s\n    user    0m0.091s\n    sys     0m0.013s\n\n  After:\n\n    real    0m0.058s\n    user    0m0.050s\n    sys     0m0.005s\n\n  # linux.git\n  $ time git --no-pager log \\\n    -L:build_restore_work_registers:arch/mips/mm/tlbex.c -1 v5.2\n\n  Before:\n\n    real   0m1.129s\n    user   0m1.061s\n    sys    0m0.069s\n\n  After:\n\n    real   0m0.096s\n    user   0m0.087s\n    sys    0m0.009s\n\nSigned-off-by: SZEDER Gábor <szeder.dev@gmail.com>\n---\n\nNotes:\n    FWIW, that line-level log sets 'limited' in addition to 'topo_order'\n    thing was already part of the first submitted iteration of the\n    line-level log patch series:\n    \n    https://public-inbox.org/git/1277558857-23103-4-git-send-email-struggleyb.nku@gmail.com/#Z30revision.c\n    \n    But it was never discussed during review.\n\n revision.c | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 6bdfcb38cd..7a9dc54771 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -2658,6 +2658,12 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s\n \tif (revs->diffopt.objfind)\n \t\trevs->simplify_history = 0;\n \n+\tif (revs->line_level_traverse) {\n+\t\tif (want_ancestry(revs))\n+\t\t\trevs->limited = 1;\n+\t\trevs->topo_order = 1;\n+\t}\n+\n \tif (revs->topo_order && !generation_numbers_enabled(the_repository))\n \t\trevs->limited = 1;\n \n@@ -2677,11 +2683,6 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s\n \n \trevs->diffopt.abbrev = revs->abbrev;\n \n-\tif (revs->line_level_traverse) {\n-\t\trevs->limited = 1;\n-\t\trevs->topo_order = 1;\n-\t}\n-\n \tdiff_setup_done(&revs->diffopt);\n \n \tgrep_commit_pattern_type(GREP_PATTERN_TYPE_UNSPECIFIED,\n-- \n2.23.0.349.g73f10e387d\n\n"},{"id":"380701","messageId":"8893430f-e83c-85ab-2058-14e49580242b@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-3-szeder.dev@gmail.com","subject":"Re: [RFC PATCH 2/5] line-log: remove unused fields from 'struct line_log_data'","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-08-19T11:53:20Z","receivedAt":"2019-08-19T11:53:25Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 8/18/2019 2:27 PM, SZEDER Gábor wrote:\n> Remove the unused fields 'status', 'arg_alloc', 'arg_nr' and 'args'\n> from 'struct line_log_data'.  They were already part of the struct\n> when it was introduced in commit 12da1d1f6 (Implement line-history\n> search (git log -L), 2013-03-28), but as far as I can tell none of\n> them have ever been actually used.\n\nGood cleanup! \n\n-Stolee\n"},{"id":"380702","messageId":"a3f8b468-5ee5-4056-db67-bb8ba5390002@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-1-szeder.dev@gmail.com","subject":"Re: [RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-08-19T12:00:11Z","receivedAt":"2019-08-19T12:00:14Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 8/18/2019 2:27 PM, SZEDER Gábor wrote:\n> Line-level log performs a preprocessing step in\n> prepare_revision_walk(), during which it filters and rewrites history\n> to keep only commits modifying the given line range.  This\n> preprocessing causes significant delay before the first commit is\n> shown, wastes CPU time when the user asks only for a few commits, and\n> does parent rewriting with no way to turn it off.\n> \n> This patch series addresses these issues by integrating line-level log\n> filtering into the revision walking machinery and making it work\n> together with generation number-based topo-ordering (though for now\n> only in the case when the user doesn't explicitly asks for parent\n> rewriting, which is probably the common case).\n> \n> The first two patches are quite straightforward (and arguably somewhat\n> unrelated), but the rest deals with history traversal and parent\n> rewriting, which I don't usually do, hence the RFC.\n\nHi Szeder,\n\nThanks for sending this series! I'm particularly excited about it\nbecause we recently got a bug report from a user in the Windows OS\nrepo about \"git log -L\" being very slow. I put it on the backlog [1]\nbut haven't had time to investigate it myself. After we are done\nupdating to v2.23.0 [2], I'll have time to test your changes on\nthe Windows repo. I anticipate your change to provide a massive\nboost.\n\nIn the meantime, your first three patches look good to me. I'll\ndig more into the last two at the same time as I run performance\ntests.\n\nThanks,\n-Stolee\n\n[1] https://github.com/microsoft/git/issues/166\n[2] https://github.com/microsoft/git/pull/165\n"},{"id":"380703","messageId":"20190819123431.GT20404@szeder.dev","threadId":"51666","inReplyTo":"20190818182801.7580-5-szeder.dev@gmail.com","subject":"Re: [RFC PATCH 4/5] line-log: more responsive, incremental 'git log -L'","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-19T12:34:31Z","receivedAt":"2019-08-19T12:34:38Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sun, Aug 18, 2019 at 08:28:00PM +0200, SZEDER Gábor wrote:\n> The current line-level log implementation performs a preprocessing\n> step in prepare_revision_walk(), during which the line_log_filter()\n> function filters and rewrites history to keep only commits modifying\n> the given line range.  This preprocessing affects both responsiveness\n> and correctness:\n> \n>   - Git doesn't produce any output during this preprocessing step.\n>     Checking whether a commit modified the given line range is\n>     somewhat expensive, so depending on the size of the given revision\n>     range this preprocessing can result in a significant delay before\n>     the first commit is shown.\n> \n>   - Limiting the number of displayed commits (e.g. 'git log -3 -L...')\n>     doesn't limit the amount of work during preprocessing, because\n>     that limit is applied during history traversal.  Alas, by that\n>     point this expensive preprocessing step has already churned\n>     through the whole revision range to find all commits modifying the\n>     revision range, even though only a few of them need to be shown.\n\ns/revision range/line range/\n\n"},{"id":"380704","messageId":"db9984f2-1f5d-efef-2bf6-689e3b440d26@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-5-szeder.dev@gmail.com","subject":"Re: [RFC PATCH 4/5] line-log: more responsive, incremental 'git log -L'","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-08-19T12:43:31Z","receivedAt":"2019-08-19T12:43:34Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 8/18/2019 2:28 PM, SZEDER Gábor wrote:\n> To be clear: this patch doesn't actually optimize the line-level log,\n> but merely moves most of the work from the preprocessing step to the\n> history travelsal, so the commits modifying the line range can be\n\ns/travelsal/traversal/\n\n-Stolee\n"},{"id":"380705","messageId":"20190819130323.GU20404@szeder.dev","threadId":"51666","inReplyTo":"a3f8b468-5ee5-4056-db67-bb8ba5390002@gmail.com","subject":"Re: [RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-19T13:03:23Z","receivedAt":"2019-08-19T13:03:30Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Aug 19, 2019 at 08:00:11AM -0400, Derrick Stolee wrote:\n> On 8/18/2019 2:27 PM, SZEDER Gábor wrote:\n> > Line-level log performs a preprocessing step in\n> > prepare_revision_walk(), during which it filters and rewrites history\n> > to keep only commits modifying the given line range.  This\n> > preprocessing causes significant delay before the first commit is\n> > shown, wastes CPU time when the user asks only for a few commits, and\n> > does parent rewriting with no way to turn it off.\n> > \n> > This patch series addresses these issues by integrating line-level log\n> > filtering into the revision walking machinery and making it work\n> > together with generation number-based topo-ordering (though for now\n> > only in the case when the user doesn't explicitly asks for parent\n> > rewriting, which is probably the common case).\n> > \n> > The first two patches are quite straightforward (and arguably somewhat\n> > unrelated), but the rest deals with history traversal and parent\n> > rewriting, which I don't usually do, hence the RFC.\n> \n> Hi Szeder,\n> \n> Thanks for sending this series! I'm particularly excited about it\n> because we recently got a bug report from a user in the Windows OS\n> repo about \"git log -L\" being very slow. I put it on the backlog [1]\n> but haven't had time to investigate it myself. After we are done\n> updating to v2.23.0 [2], I'll have time to test your changes on\n> the Windows repo. I anticipate your change to provide a massive\n> boost.\n\nWell, it depends on what you mean by \"boost\"...  As discussed in patch\n4's commit message, this series doesn't really optimizes much, and the\ntotal amount of work to be done remains the same, except that 'git log\n-L... -<N>' will be able to return early.  So when you benchmark it\nwith e.g. 'time git log -L... >/dev/null', then you won't see much\ndifference, as it will still take just about as looooong as before,\napart from the faster generation numbers-based topo-ordering.  (But I\nhave a few WIP patches waiting to be cleaned up that might bring about\n3-4x speedup in general.)\n\nIn the meantime, until these changes trickle into a Git release, for a\nfaster line-level log I would recommend to:\n\n  - Limit the revision range up front, i.e.:\n\n      git log -L... ^a-not-too-old-version\n\n    because this can greatly reduce the amount of commits that that\n    expensive preprocessing step has to churn through.\n\n  - Use '--no-renames'.  Although it won't follow the evolution of the\n    line range over file renames, this might be an acceptable\n    compromise.  (this is what those WIP patches are focusing on)\n\n  - Or both.\n\n"},{"id":"380707","messageId":"5611dad6-94fe-e4e1-c06d-7dd0642be3ae@gmail.com","threadId":"51666","inReplyTo":"20190819130323.GU20404@szeder.dev","subject":"Re: [RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-08-19T14:50:48Z","receivedAt":"2019-08-19T14:50:51Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 8/19/2019 9:03 AM, SZEDER Gábor wrote:\n> On Mon, Aug 19, 2019 at 08:00:11AM -0400, Derrick Stolee wrote:\n>> On 8/18/2019 2:27 PM, SZEDER Gábor wrote:\n>>> Line-level log performs a preprocessing step in\n>>> prepare_revision_walk(), during which it filters and rewrites history\n>>> to keep only commits modifying the given line range.  This\n>>> preprocessing causes significant delay before the first commit is\n>>> shown, wastes CPU time when the user asks only for a few commits, and\n>>> does parent rewriting with no way to turn it off.\n>>>\n>>> This patch series addresses these issues by integrating line-level log\n>>> filtering into the revision walking machinery and making it work\n>>> together with generation number-based topo-ordering (though for now\n>>> only in the case when the user doesn't explicitly asks for parent\n>>> rewriting, which is probably the common case).\n>>>\n>>> The first two patches are quite straightforward (and arguably somewhat\n>>> unrelated), but the rest deals with history traversal and parent\n>>> rewriting, which I don't usually do, hence the RFC.\n>>\n>> Hi Szeder,\n>>\n>> Thanks for sending this series! I'm particularly excited about it\n>> because we recently got a bug report from a user in the Windows OS\n>> repo about \"git log -L\" being very slow. I put it on the backlog [1]\n>> but haven't had time to investigate it myself. After we are done\n>> updating to v2.23.0 [2], I'll have time to test your changes on\n>> the Windows repo. I anticipate your change to provide a massive\n>> boost.\n> \n> Well, it depends on what you mean by \"boost\"...  As discussed in patch\n> 4's commit message, this series doesn't really optimizes much, and the\n> total amount of work to be done remains the same, except that 'git log\n> -L... -<N>' will be able to return early.  So when you benchmark it\n> with e.g. 'time git log -L... >/dev/null', then you won't see much\n> difference, as it will still take just about as looooong as before,\n> apart from the faster generation numbers-based topo-ordering.  (But I\n> have a few WIP patches waiting to be cleaned up that might bring about\n> 3-4x speedup in general.)\n> \n> In the meantime, until these changes trickle into a Git release, for a\n> faster line-level log I would recommend to:\n> \n>   - Limit the revision range up front, i.e.:\n> \n>       git log -L... ^a-not-too-old-version\n> \n>     because this can greatly reduce the amount of commits that that\n>     expensive preprocessing step has to churn through.\n> \n>   - Use '--no-renames'.  Although it won't follow the evolution of the\n>     line range over file renames, this might be an acceptable\n>     compromise.  (this is what those WIP patches are focusing on)\n> \n>   - Or both.\n\nUsually when I'm testing something involving the --topo-order logic,\nI'll use a simple \"-10\" to limit to something similar to a \"first page\".\n\nIn this line-log case, I'll use \"-1\" to just get the top result, as that\nis essentially how long it takes before the user gets some feedback.\n\nHere are the results using a random path I picked out from the Windows\nrepo (it was only changed ~10 times in the 4.5 million commits):\n\nBefore:\n\nreal    2m7.308s\nreal    2m8.572s\n\nWith Patch 4:\n\nreal    0m38.628s\nreal    0m38.477s\n\nWith Patch 5:\n\nreal    0m24.685s\nreal    0m24.310s\n\nFor the specific file in the bug report from a real user, I got\nthese numbers:\n\nreal    0m32.293s (patch 4)\nreal    0m19.362s (patch 5)\n\nNote that I don't include the \"without patch\" numbers. For some\nreason the path provided is particularly nasty and caused 20,000+\nmissing blobs to be downloaded one-by-one (remember: VFS for Git\nhas many partial-clone-like behaviors). I canceled my test after 55\nminutes. I'll dig in more to see what is going on, since only 37\ncommits actually change that path.\n\nThanks so much for finding these \"easy\" wins. Your changes are\nnicely isolated, but give us a target to improve even further!\n\nI expect that we will incorporate your commits into microsoft/git\nvery early.\n\nThanks,\n-Stolee\n\n"},{"id":"380708","messageId":"20190819150245.GV20404@szeder.dev","threadId":"51666","inReplyTo":"5611dad6-94fe-e4e1-c06d-7dd0642be3ae@gmail.com","subject":"Re: [RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-19T15:02:45Z","receivedAt":"2019-08-19T15:02:51Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:\n> Note that I don't include the \"without patch\" numbers. For some\n> reason the path provided is particularly nasty and caused 20,000+\n> missing blobs to be downloaded one-by-one (remember: VFS for Git\n> has many partial-clone-like behaviors). I canceled my test after 55\n> minutes. I'll dig in more to see what is going on, since only 37\n> commits actually change that path.\n\nDon't bother digging into it, I know why it happens (and how to avoid\nit! :), but don't have the time right now to explain.\n\n"},{"id":"380714","messageId":"6a576e13-79e6-43be-c4a8-065e7a8310ea@gmail.com","threadId":"51666","inReplyTo":"20190819150245.GV20404@szeder.dev","subject":"Re: [RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-08-19T16:12:32Z","receivedAt":"2019-08-19T16:12:36Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 8/19/2019 11:02 AM, SZEDER Gábor wrote:\n> On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:\n>> Note that I don't include the \"without patch\" numbers. For some\n>> reason the path provided is particularly nasty and caused 20,000+\n>> missing blobs to be downloaded one-by-one (remember: VFS for Git\n>> has many partial-clone-like behaviors). I canceled my test after 55\n>> minutes. I'll dig in more to see what is going on, since only 37\n>> commits actually change that path.\n> \n> Don't bother digging into it, I know why it happens (and how to avoid\n> it! :), but don't have the time right now to explain.\n\nGreat!  I look forward to your explanation and fix later.\n\nJust to be sure we've got the same issue, here is a section of the\ncall stack in the hot portion:\n\nline_log_filter\n+ queue_diffs\n  + diffcore_std\n    + diffcore_rename\n      + diff_populate_filespec\n\nThanks,\n-Stolee\n"},{"id":"380882","messageId":"20190821110717.GX20404@szeder.dev","threadId":"51666","inReplyTo":"6a576e13-79e6-43be-c4a8-065e7a8310ea@gmail.com","subject":"Re: [RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-21T11:07:17Z","receivedAt":"2019-08-21T11:07:24Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Aug 19, 2019 at 12:12:32PM -0400, Derrick Stolee wrote:\n> On 8/19/2019 11:02 AM, SZEDER Gábor wrote:\n> > On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:\n> >> Note that I don't include the \"without patch\" numbers. For some\n> >> reason the path provided is particularly nasty and caused 20,000+\n> >> missing blobs to be downloaded one-by-one (remember: VFS for Git\n> >> has many partial-clone-like behaviors). I canceled my test after 55\n> >> minutes. I'll dig in more to see what is going on, since only 37\n> >> commits actually change that path.\n> > \n> > Don't bother digging into it, I know why it happens (and how to avoid\n> > it! :), but don't have the time right now to explain.\n> \n> Great!  I look forward to your explanation and fix later.\n> \n> Just to be sure we've got the same issue, here is a section of the\n> call stack in the hot portion:\n> \n> line_log_filter\n> + queue_diffs\n>   + diffcore_std\n>     + diffcore_rename\n>       + diff_populate_filespec\n\nHmm, interesting.  Certainly most of the time is wasted in\nqueue_diffs(), but in my perf measurements diff_tree_oid() is\nresponsible for most of that, not diffcore_std().  This might still be\nthe same issue, though, but perhaps VFS for Git shifts the balance.\n\nWe'll see, here are my patches to address that diff_tree_oid()\nslowness:\n\nhttps://public-inbox.org/git/20190821110424.18184-1-szeder.dev@gmail.com/T/\n\n"},{"id":"395118","messageId":"459f2978-03f1-a58f-0dec-d0376fec5201@gmail.com","threadId":"51666","inReplyTo":"20190818182801.7580-1-szeder.dev@gmail.com","subject":"Re: [RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2020-04-09T12:17:41Z","receivedAt":"2020-04-09T12:17:49Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 8/18/2019 2:27 PM, SZEDER Gábor wrote:\n> Line-level log performs a preprocessing step in\n> prepare_revision_walk(), during which it filters and rewrites history\n> to keep only commits modifying the given line range.  This\n> preprocessing causes significant delay before the first commit is\n> shown, wastes CPU time when the user asks only for a few commits, and\n> does parent rewriting with no way to turn it off.\n> \n> This patch series addresses these issues by integrating line-level log\n> filtering into the revision walking machinery and making it work\n> together with generation number-based topo-ordering (though for now\n> only in the case when the user doesn't explicitly asks for parent\n> rewriting, which is probably the common case).\n> \n> The first two patches are quite straightforward (and arguably somewhat\n> unrelated), but the rest deals with history traversal and parent\n> rewriting, which I don't usually do, hence the RFC.\n> \n> \n> SZEDER Gábor (5):\n>   completion: offer '--(no-)patch' among 'git log' options\n>   line-log: remove unused fields from 'struct line_log_data'\n>   t4211-line-log: add tests for parent oids\n>   line-log: more responsive, incremental 'git log -L'\n>   line-log: try to use generation number-based topo-ordering\n\nHi Szeder,\n\nI was taking inventory of our issues especially around history now\nthat the changed-path Bloom filters are close to wrapping up. What's\nthe status on this RFC? Looking at it now, I understand the situation\nbetter and could help review a bit more than before. Do you have more\ncontext as to the situation on this series?\n\nThanks,\n-Stolee\n"},{"id":"396118","messageId":"20200424090241.GA5925@szeder.dev","threadId":"51666","inReplyTo":"459f2978-03f1-a58f-0dec-d0376fec5201@gmail.com","subject":"Re: [RFC PATCH 0/5] line-log: towards a more responsive, incremental 'git log -L'","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2020-04-24T09:02:41Z","receivedAt":"2020-04-24T09:02:51Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Apr 09, 2020 at 08:17:41AM -0400, Derrick Stolee wrote:\n> On 8/18/2019 2:27 PM, SZEDER Gábor wrote:\n> > Line-level log performs a preprocessing step in\n> > prepare_revision_walk(), during which it filters and rewrites history\n> > to keep only commits modifying the given line range.  This\n> > preprocessing causes significant delay before the first commit is\n> > shown, wastes CPU time when the user asks only for a few commits, and\n> > does parent rewriting with no way to turn it off.\n> > \n> > This patch series addresses these issues by integrating line-level log\n> > filtering into the revision walking machinery and making it work\n> > together with generation number-based topo-ordering (though for now\n> > only in the case when the user doesn't explicitly asks for parent\n> > rewriting, which is probably the common case).\n> > \n> > The first two patches are quite straightforward (and arguably somewhat\n> > unrelated), but the rest deals with history traversal and parent\n> > rewriting, which I don't usually do, hence the RFC.\n> > \n> > \n> > SZEDER Gábor (5):\n> >   completion: offer '--(no-)patch' among 'git log' options\n> >   line-log: remove unused fields from 'struct line_log_data'\n> >   t4211-line-log: add tests for parent oids\n> >   line-log: more responsive, incremental 'git log -L'\n> >   line-log: try to use generation number-based topo-ordering\n> \n> Hi Szeder,\n> \n> I was taking inventory of our issues especially around history now\n> that the changed-path Bloom filters are close to wrapping up.\n\nWell, I'm about to stir it up over the weekend...\n\n> What's\n> the status on this RFC? Looking at it now, I understand the situation\n> better and could help review a bit more than before. Do you have more\n> context as to the situation on this series?\n\nSadly, I haven't touched this patch series since then, other than\nrebasing it on top of new releases once or twice, but since v2.23 not\neven that.  I think I run into some conflicts and was not in the mood\nto resolve them, because with a2bb801f6a (line-log: avoid unnecessary\nfull tree diffs, 2019-08-21) the performance benefits are much lower,\nso it was not that pressing...\n\nI think patch 4 in itself is not really the right way to integrate\nline-log into the revision walking machinery:\n\n  - Line-log follows full-file renames, but it doesn't actually use\n    '--follow', but rather implements its own logic to detect them.\n    This logic is in some ways better, than '--follow', notably it can\n    follow multiple paths at once, while '--follow' only allows a\n    single path.\n    I think the rename following logic should be extracted from\n    line-log, and it should be used to implement '--follow', removing\n    some of its restrictions.\n\n  - Line-log should then be ported to use the revamped '--follow'.\n\n  - And then it's finally time for something like that patch 4, and to\n    have some \"fun\" with making explicitly requested parent rewriting\n    work (I can only remember that whenever I tried to make that work\n    my brain started to hurt :)\n \nAnyway, I think the first three patches are worth having.\n\n"}]}