{"thread":{"id":"25799","subject":"First/oldest entry in reflog dropped","startedAt":"2010-11-21T03:11:34Z","lastAt":"2010-11-25T16:15:34Z","messageCount":8,"participants":["Martin von Zweigbergk","Jeff King","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"156277","messageId":"AANLkTiktGbeSmUB75kn3q=swnw=cHvivX21OkR3sJJDC@mail.gmail.com","threadId":"25799","inReplyTo":null,"subject":"First/oldest entry in reflog dropped","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-11-21T03:11:34Z","receivedAt":"2010-11-21T03:11:34Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"Can someone explain the behavior in the execution below?\n\n# I expected this reflog...\n$ git branch tmp\n$ git reflog show refs/heads/tmp\nb60a214 refs/heads/tmp@{0}: branch: Created from master\n\n# ... and this one as well...\n$ git update-ref refs/heads/tmp HEAD^\n$ git reflog show refs/heads/tmp\n7d1a0b8 refs/heads/tmp@{0}:\nb60a214 refs/heads/tmp@{1}: branch: Created from master\n\n# ... but why is the first entry (i.e. \"branch: Created from master\")\n# dropped here?\n$ git update-ref refs/heads/tmp HEAD\n$ git reflog show refs/heads/tmp\nb60a214 refs/heads/tmp@{0}:\n7d1a0b8 refs/heads/tmp@{1}:\n\nIf the ref is updated once more (to e.g. HEAD^^) before being moved back\nto HEAD, the first entry will be shown in the output.\n\nIf this is a bug, it seems to be in reflog, rather than in update-ref,\nbecause the first entry does exist in .git/logs/refs/heads/tmp.\n\nThanks,\nMartin\n"},{"id":"156282","messageId":"20101121053545.GA10520@sigill.intra.peff.net","threadId":"25799","inReplyTo":"AANLkTiktGbeSmUB75kn3q=swnw=cHvivX21OkR3sJJDC@mail.gmail.com","subject":"Re: First/oldest entry in reflog dropped","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-11-21T05:35:46Z","receivedAt":"2010-11-21T05:35:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Nov 20, 2010 at 10:11:34PM -0500, Martin von Zweigbergk wrote:\n\n> Can someone explain the behavior in the execution below?\n> \n> # I expected this reflog...\n> $ git branch tmp\n> $ git reflog show refs/heads/tmp\n> b60a214 refs/heads/tmp@{0}: branch: Created from master\n> \n> # ... and this one as well...\n> $ git update-ref refs/heads/tmp HEAD^\n> $ git reflog show refs/heads/tmp\n> 7d1a0b8 refs/heads/tmp@{0}:\n> b60a214 refs/heads/tmp@{1}: branch: Created from master\n> \n> # ... but why is the first entry (i.e. \"branch: Created from master\")\n> # dropped here?\n> $ git update-ref refs/heads/tmp HEAD\n> $ git reflog show refs/heads/tmp\n> b60a214 refs/heads/tmp@{0}:\n> 7d1a0b8 refs/heads/tmp@{1}:\n> \n> If the ref is updated once more (to e.g. HEAD^^) before being moved back\n> to HEAD, the first entry will be shown in the output.\n> \n> If this is a bug, it seems to be in reflog, rather than in update-ref,\n> because the first entry does exist in .git/logs/refs/heads/tmp.\n\nI think it's a bug in the reflog-walking machinery, which is sort of\nbolted onto the regular revision traversal machinery. When we hit\nb60a214 the first time, we show it and set the SHOWN flag (since the\nnormal traversal machinery would not want to show a commit twice). When\nwe hit it again, simplify_commit() sees that it is SHOWN and tells us to\nskip it.\n\nHowever, the bolted-on reflog-walking machinery does have a way of\nhandling this. While we are traversing via get_revision(), we notice\nthat we are doing a reflog walk and call fake_reflog_parent. This\nfunction is responsible for replacing the actual parents of the commit\nwith a fake list consisting of the previous reflog entry (so we\nbasically pretend that the history consists of a string of commits, each\none pointing to the previous reflog entry, not the actual parent).\n\nThis function _also_ clears some flags, including the SHOWN flag, in\nwhat almost seems like a tacked-on side effect. So if we hit the same\ncommit twice, we will actually show it again. Which is what makes\nreflogs with repeated commits work at all.\n\nHowever, there is a subtle bug: it clears the flags at the very end of\nthe function. But through the function, if we see that there are no fake\nparents (because we are on the very first reflog entry), we do an early\nreturn. But we not only skip the later \"set up parents\" code, we also\naccidentally skip the \"clear SHOWN flag\" side-effect code.\n\nSo I believe we will always fail to show the very first reflog if it is\na repeated commit.\n\nThe fix, AFAICT, is to just move the flag clearing above the early\nreturns (patch below). But I have to admit I do not quite understand\nwhat the ADDED and SEEN flags are doing here, as this is the first time\nI have ever looked at the reflog-walk code. So possibly just the SHOWN\nflag should be unconditionally cleared.\n\nThis patch clears up your bug, and doesn't break any tests. But I'd\nreally like to get a second opinion on the significance of those other\nflags, or why the flag clearing was at the bottom of the function in the\nfirst place.\n\n-Peff\n\n---\ndiff --git a/reflog-walk.c b/reflog-walk.c\nindex 4879615..d5d055b 100644\n--- a/reflog-walk.c\n+++ b/reflog-walk.c\n@@ -210,44 +210,45 @@ int add_reflog_for_walk(struct reflog_walk_info *info,\n \tadd_commit_info(commit, commit_reflog, &info->reflogs);\n \treturn 0;\n }\n \n void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)\n {\n \tstruct commit_info *commit_info =\n \t\tget_commit_info(commit, &info->reflogs, 0);\n \tstruct commit_reflog *commit_reflog;\n \tstruct reflog_info *reflog;\n \n+\tcommit->object.flags &= ~(ADDED | SEEN | SHOWN);\n+\n \tinfo->last_commit_reflog = NULL;\n \tif (!commit_info)\n \t\treturn;\n \n \tcommit_reflog = commit_info->util;\n \tif (commit_reflog->recno < 0) {\n \t\tcommit->parents = NULL;\n \t\treturn;\n \t}\n \n \treflog = &commit_reflog->reflogs->items[commit_reflog->recno];\n \tinfo->last_commit_reflog = commit_reflog;\n \tcommit_reflog->recno--;\n \tcommit_info->commit = (struct commit *)parse_object(reflog->osha1);\n \tif (!commit_info->commit) {\n \t\tcommit->parents = NULL;\n \t\treturn;\n \t}\n \n \tcommit->parents = xcalloc(sizeof(struct commit_list), 1);\n \tcommit->parents->item = commit_info->commit;\n-\tcommit->object.flags &= ~(ADDED | SEEN | SHOWN);\n }\n \n void get_reflog_selector(struct strbuf *sb,\n \t\t\t struct reflog_walk_info *reflog_info,\n \t\t\t enum date_mode dmode,\n \t\t\t int shorten)\n {\n \tstruct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;\n \tstruct reflog_info *info;\n \tconst char *printed_ref;\n \n"},{"id":"156285","messageId":"alpine.DEB.1.00.1011211233570.2948@bonsai2","threadId":"25799","inReplyTo":"20101121053545.GA10520@sigill.intra.peff.net","subject":"Re: First/oldest entry in reflog dropped","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-11-21T11:36:21Z","receivedAt":"2010-11-21T11:36:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Nov 2010, Jeff King wrote:\n\n> This patch clears up your bug, and doesn't break any tests. But I'd \n> really like to get a second opinion on the significance of those other \n> flags, or why the flag clearing was at the bottom of the function in the \n> first place.\n\nThe flag clearing was at the bottom because I had the impression that \nsomething function one might want to call in that function in the future \ncould set the flags again. Maybe a goto would be appropriate here instead \nof the early returns?\n\nCiao,\nDscho\n"},{"id":"156296","messageId":"AANLkTikS00FN9-_MoSGvBMxdUefzk5K_8Zz2V14KCDLJ@mail.gmail.com","threadId":"25799","inReplyTo":"20101121053545.GA10520@sigill.intra.peff.net","subject":"Re: First/oldest entry in reflog dropped","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-11-21T22:57:46Z","receivedAt":"2010-11-21T22:57:46Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Sun, Nov 21, 2010 at 12:35 AM, Jeff King <peff@peff.net> wrote:\n> On Sat, Nov 20, 2010 at 10:11:34PM -0500, Martin von Zweigbergk wrote:\n>\n>> Can someone explain the behavior in the execution below?\n>>\n>> # I expected this reflog...\n>> $ git branch tmp\n>> $ git reflog show refs/heads/tmp\n>> b60a214 refs/heads/tmp@{0}: branch: Created from master\n>>\n>> # ... and this one as well...\n>> $ git update-ref refs/heads/tmp HEAD^\n>> $ git reflog show refs/heads/tmp\n>> 7d1a0b8 refs/heads/tmp@{0}:\n>> b60a214 refs/heads/tmp@{1}: branch: Created from master\n>>\n>> # ... but why is the first entry (i.e. \"branch: Created from master\")\n>> # dropped here?\n>> $ git update-ref refs/heads/tmp HEAD\n>> $ git reflog show refs/heads/tmp\n>> b60a214 refs/heads/tmp@{0}:\n>> 7d1a0b8 refs/heads/tmp@{1}:\n>>\n>> If the ref is updated once more (to e.g. HEAD^^) before being moved back\n>> to HEAD, the first entry will be shown in the output.\n>>\n>> If this is a bug, it seems to be in reflog, rather than in update-ref,\n>> because the first entry does exist in .git/logs/refs/heads/tmp.\n>\n> I think it's a bug in the reflog-walking machinery, which is sort of\n> bolted onto the regular revision traversal machinery. When we hit\n> b60a214 the first time, we show it and set the SHOWN flag (since the\n> normal traversal machinery would not want to show a commit twice). When\n> we hit it again, simplify_commit() sees that it is SHOWN and tells us to\n> skip it.\n>\n> However, the bolted-on reflog-walking machinery does have a way of\n> handling this. While we are traversing via get_revision(), we notice\n> that we are doing a reflog walk and call fake_reflog_parent. This\n> function is responsible for replacing the actual parents of the commit\n> with a fake list consisting of the previous reflog entry (so we\n> basically pretend that the history consists of a string of commits, each\n> one pointing to the previous reflog entry, not the actual parent).\n>\n> This function _also_ clears some flags, including the SHOWN flag, in\n> what almost seems like a tacked-on side effect. So if we hit the same\n> commit twice, we will actually show it again. Which is what makes\n> reflogs with repeated commits work at all.\n>\n> However, there is a subtle bug: it clears the flags at the very end of\n> the function. But through the function, if we see that there are no fake\n> parents (because we are on the very first reflog entry), we do an early\n> return. But we not only skip the later \"set up parents\" code, we also\n> accidentally skip the \"clear SHOWN flag\" side-effect code.\n>\n> So I believe we will always fail to show the very first reflog if it is\n> a repeated commit.\n>\n> The fix, AFAICT, is to just move the flag clearing above the early\n> returns (patch below). But I have to admit I do not quite understand\n> what the ADDED and SEEN flags are doing here, as this is the first time\n> I have ever looked at the reflog-walk code. So possibly just the SHOWN\n> flag should be unconditionally cleared.\n>\n> This patch clears up your bug, and doesn't break any tests. But I'd\n> really like to get a second opinion on the significance of those other\n> flags, or why the flag clearing was at the bottom of the function in the\n> first place.\n>\n> -Peff\n>\n> ---\n> diff --git a/reflog-walk.c b/reflog-walk.c\n> index 4879615..d5d055b 100644\n> --- a/reflog-walk.c\n> +++ b/reflog-walk.c\n> @@ -210,44 +210,45 @@ int add_reflog_for_walk(struct reflog_walk_info *info,\n>        add_commit_info(commit, commit_reflog, &info->reflogs);\n>        return 0;\n>  }\n>\n>  void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)\n>  {\n>        struct commit_info *commit_info =\n>                get_commit_info(commit, &info->reflogs, 0);\n>        struct commit_reflog *commit_reflog;\n>        struct reflog_info *reflog;\n>\n> +       commit->object.flags &= ~(ADDED | SEEN | SHOWN);\n> +\n>        info->last_commit_reflog = NULL;\n>        if (!commit_info)\n>                return;\n>\n>        commit_reflog = commit_info->util;\n>        if (commit_reflog->recno < 0) {\n>                commit->parents = NULL;\n>                return;\n>        }\n>\n>        reflog = &commit_reflog->reflogs->items[commit_reflog->recno];\n>        info->last_commit_reflog = commit_reflog;\n>        commit_reflog->recno--;\n>        commit_info->commit = (struct commit *)parse_object(reflog->osha1);\n>        if (!commit_info->commit) {\n>                commit->parents = NULL;\n>                return;\n>        }\n>\n>        commit->parents = xcalloc(sizeof(struct commit_list), 1);\n>        commit->parents->item = commit_info->commit;\n> -       commit->object.flags &= ~(ADDED | SEEN | SHOWN);\n>  }\n>\n>  void get_reflog_selector(struct strbuf *sb,\n>                         struct reflog_walk_info *reflog_info,\n>                         enum date_mode dmode,\n>                         int shorten)\n>  {\n>        struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;\n>        struct reflog_info *info;\n>        const char *printed_ref;\n>\n>\n\nGood job! And yes, if the first commit is included in any cycles, it\nseems to be dropped. I must have been blind yesterday...\n"},{"id":"156303","messageId":"20101122044252.GA7362@sigill.intra.peff.net","threadId":"25799","inReplyTo":"alpine.DEB.1.00.1011211233570.2948@bonsai2","subject":"Re: First/oldest entry in reflog dropped","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-11-22T04:42:53Z","receivedAt":"2010-11-22T04:42:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 21, 2010 at 12:36:21PM +0100, Johannes Schindelin wrote:\n\n> On Sun, 21 Nov 2010, Jeff King wrote:\n> \n> > This patch clears up your bug, and doesn't break any tests. But I'd \n> > really like to get a second opinion on the significance of those other \n> > flags, or why the flag clearing was at the bottom of the function in the \n> > first place.\n> \n> The flag clearing was at the bottom because I had the impression that \n> something function one might want to call in that function in the future \n> could set the flags again. Maybe a goto would be appropriate here instead \n> of the early returns?\n\nThat makes sense. I did a quick skim of the called code and I'm not sure\nany flags could be set, but even if I am right, I think it is better to\nbe defensive.\n\nSo let's do this, which is the equivalent behavior to your gotos, but\nthis structure makes more sense to me as a reader (and it doesn't\ninvolve goto :) ).\n\n-- >8 --\nSubject: [PATCH] reflogs: clear flags properly in corner case\n\nThe reflog-walking mechanism is based on the regular\nrevision traversal. We just rewrite the parents of each\ncommit in fake_reflog_parent to point to the commit in the\nnext reflog entry instead of the real parents.\n\nHowever, the regular revision traversal tries not to show\nthe same commit twice, and so sets the SHOWN flag on each\ncommit it shows. In a reflog, however, we may want to see\nthe same commit more than once if it appears in the reflog\nmultiple times (which easily happens, for example, if you do\na reset to a prior state).\n\nThe fake_reflog_parent function takes care of this by\nclearing flags, including SHOWN. Unfortunately, it does so\nat the very end of the function, and it is possible to\nreturn early from the function if there is no fake parent to\nset up (e.g., because we are at the very first reflog entry\non the branch). In such a case the flag is not cleared, and\nthe entry is skipped by the revision traversal machinery as\nalready shown.\n\nYou can see this by walking the log of a ref which is set to\nits very first commit more than once (the test below shows\nsuch a situation). In this case the reflog walk will fail to\nshow the entry for the initial creation of the ref.\n\nWe don't want to simply move the flag-clearing to the top of\nthe function; we want to make sure flags set during the\nfake-parent installation are also cleared. Instead, let's\nhoist the flag-clearing out of the fake_reflog_parent\nfunction entirely. It's not really about fake parents\nanyway, and the only caller is the get_revision machinery.\n\nReported-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>\nSigned-off-by: Jeff King <peff@peff.net>\n---\n reflog-walk.c          |    1 -\n revision.c             |    4 +++-\n t/t1412-reflog-loop.sh |   34 ++++++++++++++++++++++++++++++++++\n 3 files changed, 37 insertions(+), 2 deletions(-)\n create mode 100755 t/t1412-reflog-loop.sh\n\ndiff --git a/reflog-walk.c b/reflog-walk.c\nindex 4879615..5d81d39 100644\n--- a/reflog-walk.c\n+++ b/reflog-walk.c\n@@ -239,7 +239,6 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)\n \n \tcommit->parents = xcalloc(sizeof(struct commit_list), 1);\n \tcommit->parents->item = commit_info->commit;\n-\tcommit->object.flags &= ~(ADDED | SEEN | SHOWN);\n }\n \n void get_reflog_selector(struct strbuf *sb,\ndiff --git a/revision.c b/revision.c\nindex b1c1890..ded8812 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -2030,8 +2030,10 @@ static struct commit *get_revision_1(struct rev_info *revs)\n \t\trevs->commits = entry->next;\n \t\tfree(entry);\n \n-\t\tif (revs->reflog_info)\n+\t\tif (revs->reflog_info) {\n \t\t\tfake_reflog_parent(revs->reflog_info, commit);\n+\t\t\tcommit->object.flags &= ~(ADDED | SEEN | SHOWN);\n+\t\t}\n \n \t\t/*\n \t\t * If we haven't done the list limiting, we need to look at\ndiff --git a/t/t1412-reflog-loop.sh b/t/t1412-reflog-loop.sh\nnew file mode 100755\nindex 0000000..7f519e5\n--- /dev/null\n+++ b/t/t1412-reflog-loop.sh\n@@ -0,0 +1,34 @@\n+#!/bin/sh\n+\n+test_description='reflog walk shows repeated commits again'\n+. ./test-lib.sh\n+\n+test_expect_success 'setup commits' '\n+\ttest_tick &&\n+\techo content >file && git add file && git commit -m one &&\n+\tgit tag one &&\n+\techo content >>file && git add file && git commit -m two &&\n+\tgit tag two\n+'\n+\n+test_expect_success 'setup reflog with alternating commits' '\n+\tgit checkout -b topic &&\n+\tgit reset one &&\n+\tgit reset two &&\n+\tgit reset one &&\n+\tgit reset two\n+'\n+\n+test_expect_success 'reflog shows all entries' '\n+\tcat >expect <<-\\EOF\n+\t\ttopic@{0} two: updating HEAD\n+\t\ttopic@{1} one: updating HEAD\n+\t\ttopic@{2} two: updating HEAD\n+\t\ttopic@{3} one: updating HEAD\n+\t\ttopic@{4} branch: Created from HEAD\n+\tEOF\n+\tgit log -g --format=\"%gd %gs\" topic >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_done\n-- \n1.7.3.2.509.g15259\n"},{"id":"156306","messageId":"alpine.DEB.1.00.1011221032180.2948@bonsai2","threadId":"25799","inReplyTo":"20101122044252.GA7362@sigill.intra.peff.net","subject":"Re: First/oldest entry in reflog dropped","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-11-22T09:32:44Z","receivedAt":"2010-11-22T09:32:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Nov 2010, Jeff King wrote:\n\n> Subject: [PATCH] reflogs: clear flags properly in corner case\n> \n> [...]\n\nACK,\nDscho\n"},{"id":"156459","messageId":"7vzksztv6f.fsf@alter.siamese.dyndns.org","threadId":"25799","inReplyTo":"20101122044252.GA7362@sigill.intra.peff.net","subject":"Re: First/oldest entry in reflog dropped","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-24T00:35:52Z","receivedAt":"2010-11-24T00:35:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sun, Nov 21, 2010 at 12:36:21PM +0100, Johannes Schindelin wrote:\n>\n>> On Sun, 21 Nov 2010, Jeff King wrote:\n>> \n>> > This patch clears up your bug, and doesn't break any tests. But I'd \n>> > really like to get a second opinion on the significance of those other \n>> > flags, or why the flag clearing was at the bottom of the function in the \n>> > first place.\n>> \n>> The flag clearing was at the bottom because I had the impression that \n>> something function one might want to call in that function in the future \n>> could set the flags again. Maybe a goto would be appropriate here instead \n>> of the early returns?\n>\n> That makes sense. I did a quick skim of the called code and I'm not sure\n> any flags could be set, but even if I am right, I think it is better to\n> be defensive.\n>\n> So let's do this, which is the equivalent behavior to your gotos, but\n> this structure makes more sense to me as a reader (and it doesn't\n> involve goto :) ).\n\nI have a feeling that we probably should have structured the code a bit\nmore modularly, placing some info in \"rev\" that tells us how to \"pop\" a\ncommit from the rev->list (typically \"not the ones that we have shown\"),\nwhat other commits to push back into the queue (typically, \"all the\nparents that are not interesting\"), and what side effects we should cause\nwhen we do so (typically, \"mark uninteresting parents\"), etc., instead of\nthe current \"if we are walking reflog, here is the special codepath we\ntake\", so that the walking is more generalized when we did the reflog\nwalking (in fact, if we did this properly we probably wouldn't be calling\nit \"bolted on\").  But for now let's refrain from doing such a rewrite.\n\nThanks, both.\n"},{"id":"156560","messageId":"20101125161530.GB24426@sigill.intra.peff.net","threadId":"25799","inReplyTo":"7vzksztv6f.fsf@alter.siamese.dyndns.org","subject":"Re: First/oldest entry in reflog dropped","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-11-25T16:15:34Z","receivedAt":"2010-11-25T16:15:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 23, 2010 at 04:35:52PM -0800, Junio C Hamano wrote:\n\n> > So let's do this, which is the equivalent behavior to your gotos, but\n> > this structure makes more sense to me as a reader (and it doesn't\n> > involve goto :) ).\n> \n> I have a feeling that we probably should have structured the code a bit\n> more modularly, placing some info in \"rev\" that tells us how to \"pop\" a\n> commit from the rev->list (typically \"not the ones that we have shown\"),\n> what other commits to push back into the queue (typically, \"all the\n> parents that are not interesting\"), and what side effects we should cause\n> when we do so (typically, \"mark uninteresting parents\"), etc., instead of\n> the current \"if we are walking reflog, here is the special codepath we\n> take\", so that the walking is more generalized when we did the reflog\n> walking (in fact, if we did this properly we probably wouldn't be calling\n> it \"bolted on\").  But for now let's refrain from doing such a rewrite.\n\nFWIW, I agree with all of that. I don't think it's worth fixing now, but\nperhaps in libgit2. :)\n\n-Peff\n"}]}