{"thread":{"id":"28890","subject":"RFH: unexpected reflog behavior with --since=","startedAt":"2011-11-09T00:22:41Z","lastAt":"2011-11-12T06:50:28Z","messageCount":13,"participants":["Eric Raible","Jeff King","Jay Soffian","Miles Bader","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179170","messageId":"4EB9C7D1.30201@nextest.com","threadId":"28890","inReplyTo":null,"subject":"RFH: unexpected reflog behavior with --since=","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2011-11-09T00:22:41Z","receivedAt":"2011-11-09T00:22:41Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"I'm trying to leverage the reflog to speed up our $dayjob build procedure\n(it's complicated), and found unexpected behavior when limiting reflog\noutput with --since.\n\n    git init reflog-test\n    cd reflog-test\n\n    touch a && git add a && git commit -m'add a'\n    sleep 1\n    touch b && git add b && git commit -m'add b'\n\n    # add_b will be the time that b was added (email ends with '>')\n    add_b=$(tail -1 .git/logs/HEAD | perl -e \"print( <> =~ m/> (\\S+)/ )\")\n\n    # It's reported correctly here:\n    git log -g --oneline --since=$add_b\n\n    # But after a reset no history isn't shown.\n    git reset --hard HEAD^\n    git log -g --oneline --since=$add_b\n\nIs this a bug?  Of course everything is reported when --since isn't used,\nbut not so when limited with --since.\n\n1.7.7.1.msysgit.0\n\nThanks - Eric\n"},{"id":"179220","messageId":"20111109220128.GA31535@sigill.intra.peff.net","threadId":"28890","inReplyTo":"4EB9C7D1.30201@nextest.com","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-09T22:01:28Z","receivedAt":"2011-11-09T22:01:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 08, 2011 at 04:22:41PM -0800, Eric Raible wrote:\n\n>     # It's reported correctly here:\n>     git log -g --oneline --since=$add_b\n> \n>     # But after a reset no history isn't shown.\n>     git reset --hard HEAD^\n>     git log -g --oneline --since=$add_b\n> \n> Is this a bug?  Of course everything is reported when --since isn't used,\n> but not so when limited with --since.\n\nIt's sort of a bug. And sort of a missing feature.\n\nIn the normal revision walking case, git walks the history graph\nbackwards, hitting the parent of each commit (and when there are\nmultiple lines of history, we traverse them in commit timestamp order).\n\nSo \"--since\" works not just by omitting non-matching commits from the\noutput, but also by stopping the traversal when we go too far back in\ntime. In a sense, this is purely an optimization, as it shouldn't change\nthe output. But it's an important one, because it makes looking back in\ntime O(how far back) instead of O(size of all history).\n\nThis optimization breaks down badly, of course, in the face of clock\nskew (i.e., a commit whose timestamp is further back than its parent).\nThere are a few tricks we do to avoid small runs of moderate skew, and\nin practice it works well.\n\nNow let's look at reflog walking. It's kind of bolted on to the side\nof the revision traversal machinery. We walk through the reflog\nbackwards and pretend that entry N's parent is entry N-1 (you can see\nthis if you do \"git log -g -p\", for example; you see the patch versus\nthe last reflog entry, not the patch against the commit's true parent).\n\nIn the case of rewound history (like the reset you showed above), this\nmeans that the history graph will appear to have bad clock skew. The\ntimestamp of HEAD@{0} is going to be much earlier than its pretend\nparent, HEAD@{1}. And the \"--since\" optimization is going to cut off\ntraversal, even though there are more interesting commits to be shown.\n\nSo in that sense, I think it's a bug, and we should probably disable the\nexit-early-from-traversal optimization when we're walking reflogs.\n\nBut it may also be a misfeature, because it's not clear what you're\nactually trying to limit by. We have commit timestamps, of course, but\nwhen we are walking reflogs, we also have reflog timestamps. Did you\nactually want to say \"show me all commits in the reflog, in reverse\nreflog order, omitting commits that happened before time t\"? Or did you\nreally mean \"show me the reflog entries that happened before time t,\nregardless of their commit timestamp\"?\n\nIn the latter case, we would either need a new specifier (like\n\"--reflog-since\"), or to rewrite the commit timestamp when we rewrite\nthe parent pointers.\n\nThe latter has a certain elegance to it (we are making a pretend linear\nhistory graph out of the reflog, so faking the timestamps to be sensible\nand in order is a logical thing to do) but I worry about lying too much\nin the output. Something like \"git log -g --format=%cd\" would now have\nthe fake timestamp in the output. But then, we already show the fake\nparents in the output, so I don't know that this is any worse.\n\n-Peff\n"},{"id":"179222","messageId":"20111109222032.GB31535@sigill.intra.peff.net","threadId":"28890","inReplyTo":"20111109220128.GA31535@sigill.intra.peff.net","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-09T22:20:32Z","receivedAt":"2011-11-09T22:20:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 09, 2011 at 05:01:28PM -0500, Jeff King wrote:\n\n> In the latter case, we would either need a new specifier (like\n> \"--reflog-since\"), or to rewrite the commit timestamp when we rewrite\n> the parent pointers.\n> \n> The latter has a certain elegance to it (we are making a pretend linear\n> history graph out of the reflog, so faking the timestamps to be sensible\n> and in order is a logical thing to do) but I worry about lying too much\n> in the output. Something like \"git log -g --format=%cd\" would now have\n> the fake timestamp in the output. But then, we already show the fake\n> parents in the output, so I don't know that this is any worse.\n\nThis patch (which is below) turns out to be absurdly simple. And it\nactually still prints the original commit timestamp, because we end up\nreparsing it out of the commit object during the pretty-print phase.\n\nSo I think the only decision is whether \"--since\" should respect the\ncommit timestamps (and be used as a sort of \"grep\" filter for\ntimestamps), or whether it should be respecting the fake history we\ncreate when doing a reflog walk.\n\nI think I am leaning towards the latter. It seems to me to be the more\nlikely guess for what the user would want. And there is real benefit to\ndoing it in git, since we can stop the traversal early. In the\n\"grep-like\" case, doing it inside git is not really any more efficient\nthan filtering in a pipeline, like:\n\n  git log -g --format='%ct %H' |\n  awk '{ print $2 if $1 < SOME_TIMESTAMP }'\n\nOf course we could still offer both (with a \"--reflog-since\" type of\noption). We'd also need to turn off the optimization for \"--since\", and\nthen check whether \"--until\" has a similar bug (and offer\n\"--reflog-until\").\n\ndiff --git a/reflog-walk.c b/reflog-walk.c\nindex 5d81d39..2e5b270 100644\n--- a/reflog-walk.c\n+++ b/reflog-walk.c\n@@ -231,6 +231,7 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)\n \treflog = &commit_reflog->reflogs->items[commit_reflog->recno];\n \tinfo->last_commit_reflog = commit_reflog;\n \tcommit_reflog->recno--;\n+\tcommit->date = reflog->timestamp;\n \tcommit_info->commit = (struct commit *)parse_object(reflog->osha1);\n \tif (!commit_info->commit) {\n \t\tcommit->parents = NULL;\n"},{"id":"179223","messageId":"20111109222654.GC31535@sigill.intra.peff.net","threadId":"28890","inReplyTo":"20111109222032.GB31535@sigill.intra.peff.net","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-09T22:26:54Z","receivedAt":"2011-11-09T22:26:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 09, 2011 at 05:20:32PM -0500, Jeff King wrote:\n\n>   git log -g --format='%ct %H' |\n>   awk '{ print $2 if $1 < SOME_TIMESTAMP }'\n\nHmm, that is obviously not valid awk syntax. My brain has been too fried\nby perl. And the comparison goes the wrong way. A (closer to) working\nexample would be:\n\n  git log -g --format='%ct %H' |\n  perl -alne 'print $F[1] if $F[0] > SOME_TIMESTAMP'\n\nBut hopefully you get the point.\n\n-Peff\n"},{"id":"179249","messageId":"4EBB81EA.6060303@nextest.com","threadId":"28890","inReplyTo":"20111109220128.GA31535@sigill.intra.peff.net","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2011-11-10T07:48:58Z","receivedAt":"2011-11-10T07:48:58Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"On 11/9/2011 2:01 PM, Jeff King wrote:\n> On Tue, Nov 08, 2011 at 04:22:41PM -0800, Eric Raible wrote:\n> \n> [explanation how --since is used to limits traversal omitted]\n\nYes, all that is as expected, and makes sense.\n\n> Now let's look at reflog walking. It's kind of bolted on to the side\n> of the revision traversal machinery. We walk through the reflog\n> backwards and pretend that entry N's parent is entry N-1 (you can see\n> this if you do \"git log -g -p\", for example; you see the patch versus\n> the last reflog entry, not the patch against the commit's true parent).\n> \n> In the case of rewound history (like the reset you showed above), this\n> means that the history graph will appear to have bad clock skew. The\n> timestamp of HEAD@{0} is going to be much earlier than its pretend\n> parent, HEAD@{1}. And the \"--since\" optimization is going to cut off\n> traversal, even though there are more interesting commits to be shown.\n> \n> So in that sense, I think it's a bug, and we should probably disable the\n> exit-early-from-traversal optimization when we're walking reflogs.\n\nIndeed.  Seems like a case of an optimization leading to an incorrect result.\n\n> But it may also be a misfeature, because it's not clear what you're\n> actually trying to limit by. We have commit timestamps, of course, but\n> when we are walking reflogs, we also have reflog timestamps. Did you\n> actually want to say \"show me all commits in the reflog, in reverse\n> reflog order, omitting commits that happened before time t\"? Or did you\n> really mean \"show me the reflog entries that happened before time t,\n> regardless of their commit timestamp\"?\n\nI meant \"show me the reflog entries that happened *since* time t,\nregardless of their commit timestamp.\n\n> In the latter case, we would either need a new specifier (like\n> \"--reflog-since\"), or to rewrite the commit timestamp when we rewrite\n> the parent pointers.\n> \n> The latter has a certain elegance to it (we are making a pretend linear\n> history graph out of the reflog, so faking the timestamps to be sensible\n> and in order is a logical thing to do) but I worry about lying too much\n> in the output. Something like \"git log -g --format=%cd\" would now have\n> the fake timestamp in the output. But then, we already show the fake\n> parents in the output, so I don't know that this is any worse.\n\nSince -g is asking specifying for the reflog, and since the reflog has\nits own timestamps, I would expect that those timestamps be used.\n"},{"id":"179261","messageId":"20111110075941.GA28148@sigill.intra.peff.net","threadId":"28890","inReplyTo":"4EBB81EA.6060303@nextest.com","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-10T07:59:41Z","receivedAt":"2011-11-10T07:59:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 09, 2011 at 11:48:58PM -0800, Eric Raible wrote:\n\n> > But it may also be a misfeature, because it's not clear what you're\n> > actually trying to limit by. We have commit timestamps, of course, but\n> > when we are walking reflogs, we also have reflog timestamps. Did you\n> > actually want to say \"show me all commits in the reflog, in reverse\n> > reflog order, omitting commits that happened before time t\"? Or did you\n> > really mean \"show me the reflog entries that happened before time t,\n> > regardless of their commit timestamp\"?\n> \n> I meant \"show me the reflog entries that happened *since* time t,\n> regardless of their commit timestamp.\n\nErr, yeah, sorry. Somehow in the middle of writing the email I got\nturned backwards about which direction we were interested in.\n\nBut I think you get the point.\n\n> Since -g is asking specifying for the reflog, and since the reflog has\n> its own timestamps, I would expect that those timestamps be used.\n\nThen I think my one-liner patch should do what you want. And now it's\nnot just anecdotal evidence that I think it's the right behavior. There\nare two of us; we're _data_.\n\n-Peff\n"},{"id":"179262","messageId":"4EBB8596.6040507@nextest.com","threadId":"28890","inReplyTo":"20111109222032.GB31535@sigill.intra.peff.net","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2011-11-10T08:04:38Z","receivedAt":"2011-11-10T08:04:38Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"On 11/9/2011 2:20 PM, Jeff King wrote:\n> On Wed, Nov 09, 2011 at 05:01:28PM -0500, Jeff King wrote:\n> \n> This patch (which is below) turns out to be absurdly simple. And it\n> actually still prints the original commit timestamp, because we end up\n> reparsing it out of the commit object during the pretty-print phase.\n\nSweet!\n\n> So I think the only decision is whether \"--since\" should respect the\n> commit timestamps (and be used as a sort of \"grep\" filter for\n> timestamps), or whether it should be respecting the fake history we\n> create when doing a reflog walk.\n\nWhen -g is specified it seems less surprising for --since to respect\nthe reflog's fake history.  That's what *I* expected, anyway.\n\n> I think I am leaning towards the latter. It seems to me to be the more\n> likely guess for what the user would want. And there is real benefit to\n> doing it in git, since we can stop the traversal early. In the\n> \"grep-like\" case, doing it inside git is not really any more efficient\n> than filtering in a pipeline, like:\n> \n>   git log -g --format='%ct %H' |\n>   awk '{ print $2 if $1 < SOME_TIMESTAMP }'\n\nAnd then the sha would have to be fed back into git to be useful, eh?\n\n> Of course we could still offer both (with a \"--reflog-since\" type of\n> option). We'd also need to turn off the optimization for \"--since\", and\n> then check whether \"--until\" has a similar bug (and offer\n> \"--reflog-until\").\n\nI don't see the point of --reflog-since.  If the user specifies 'reflog'\n(either directly or with -g), then can't we just use the reflog's timestamp?\nNote: there might be good reasons, as my use of the reflog (and --since, for\nthat matter), has been very simplistic so far.\n\n> diff --git a/reflog-walk.c b/reflog-walk.c\n> index 5d81d39..2e5b270 100644\n> --- a/reflog-walk.c\n> +++ b/reflog-walk.c\n> @@ -231,6 +231,7 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)\n>  \treflog = &commit_reflog->reflogs->items[commit_reflog->recno];\n>  \tinfo->last_commit_reflog = commit_reflog;\n>  \tcommit_reflog->recno--;\n> +\tcommit->date = reflog->timestamp;\n>  \tcommit_info->commit = (struct commit *)parse_object(reflog->osha1);\n>  \tif (!commit_info->commit) {\n>  \t\tcommit->parents = NULL;\n\nIs this something you'd be willing to turn into a real patch?\nI'm certainly not qualified.\n\nThanks - Eric\n"},{"id":"179263","messageId":"20111110080851.GA28342@sigill.intra.peff.net","threadId":"28890","inReplyTo":"4EBB8596.6040507@nextest.com","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-10T08:08:51Z","receivedAt":"2011-11-10T08:08:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 10, 2011 at 12:04:38AM -0800, Eric Raible wrote:\n\n> > I think I am leaning towards the latter. It seems to me to be the more\n> > likely guess for what the user would want. And there is real benefit to\n> > doing it in git, since we can stop the traversal early. In the\n> > \"grep-like\" case, doing it inside git is not really any more efficient\n> > than filtering in a pipeline, like:\n> > \n> >   git log -g --format='%ct %H' |\n> >   awk '{ print $2 if $1 < SOME_TIMESTAMP }'\n> \n> And then the sha would have to be fed back into git to be useful, eh?\n\nIt's just illustrative. You could replace \"%H\" with the actual\ninformation you're interested in.\n\n> > Of course we could still offer both (with a \"--reflog-since\" type of\n> > option). We'd also need to turn off the optimization for \"--since\", and\n> > then check whether \"--until\" has a similar bug (and offer\n> > \"--reflog-until\").\n> \n> I don't see the point of --reflog-since.  If the user specifies 'reflog'\n> (either directly or with -g), then can't we just use the reflog's timestamp?\n> Note: there might be good reasons, as my use of the reflog (and --since, for\n> that matter), has been very simplistic so far.\n\nThe only point would be to leave \"--since\" to act on the commit\ntimestamps, so that you don't have to resort to the external grepping I\nmentioned above. However, I'm not convinced anybody even cares about\nthat use case.\n\nI think the behavior you want is much more sensible.\n\n> > diff --git a/reflog-walk.c b/reflog-walk.c\n> > index 5d81d39..2e5b270 100644\n> > --- a/reflog-walk.c\n> > +++ b/reflog-walk.c\n> > @@ -231,6 +231,7 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)\n> >  \treflog = &commit_reflog->reflogs->items[commit_reflog->recno];\n> >  \tinfo->last_commit_reflog = commit_reflog;\n> >  \tcommit_reflog->recno--;\n> > +\tcommit->date = reflog->timestamp;\n> >  \tcommit_info->commit = (struct commit *)parse_object(reflog->osha1);\n> >  \tif (!commit_info->commit) {\n> >  \t\tcommit->parents = NULL;\n> \n> Is this something you'd be willing to turn into a real patch?\n> I'm certainly not qualified.\n\nYes. We're in release freeze now, so I didn't even bother with sending\nit to Junio. But also, I'd like to gather more opinions on whether the\ndesign is the right thing (hopefully the implementation is Obviously\nCorrect. :) ).\n\n-Peff\n"},{"id":"179264","messageId":"4EBB8943.4060801@nextest.com","threadId":"28890","inReplyTo":"20111110080851.GA28342@sigill.intra.peff.net","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2011-11-10T08:20:19Z","receivedAt":"2011-11-10T08:20:19Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"On 11/10/2011 12:08 AM, Jeff King wrote:\n>>>   git log -g --format='%ct %H' |\n>>>   awk '{ print $2 if $1 < SOME_TIMESTAMP }'\n>>\n>> And then the sha would have to be fed back into git to be useful, eh?\n> \n> It's just illustrative. You could replace \"%H\" with the actual\n> information you're interested in.\n\nOf course, my thinko.\n\n> The only point would be to leave \"--since\" to act on the commit\n> timestamps, so that you don't have to resort to the external grepping I\n> mentioned above. However, I'm not convinced anybody even cares about\n> that use case.\n> \n> I think the behavior you want is much more sensible.\n\nMe too!\n\n>> Is this something you'd be willing to turn into a real patch?\n>> I'm certainly not qualified.\n> \n> Yes. We're in release freeze now, so I didn't even bother with sending\n> it to Junio. But also, I'd like to gather more opinions on whether the\n> design is the right thing (hopefully the implementation is Obviously\n> Correct. :) ).\n\nI think it's hard to argue that the current behavior (as illustrated with\nmy original example) makes sense.  Or that your patch is overly complicated.\nBut giving people time to chime in it definitely TRTTD.\n\n- Eric\n"},{"id":"179266","messageId":"CAG+J_DzfW8oZ7Mytb16q7mgnYxKxo13F2-HGgW4-esJ4GUn--Q@mail.gmail.com","threadId":"28890","inReplyTo":"20111110080851.GA28342@sigill.intra.peff.net","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-11-10T08:31:14Z","receivedAt":"2011-11-10T08:31:14Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Nov 10, 2011 at 3:08 AM, Jeff King <peff@peff.net> wrote:\n> it to Junio. But also, I'd like to gather more opinions on whether the\n> design is the right thing (hopefully the implementation is Obviously\n\nMakes sense to me, so you're at +3.\n\nj.\n"},{"id":"179272","messageId":"buok4785j8v.fsf@dhlpc061.dev.necel.com","threadId":"28890","inReplyTo":"20111110080851.GA28342@sigill.intra.peff.net","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-11-10T11:06:56Z","receivedAt":"2011-11-10T11:06:56Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n> The only point would be to leave \"--since\" to act on the commit\n> timestamps, so that you don't have to resort to the external grepping I\n> mentioned above. However, I'm not convinced anybody even cares about\n> that use case.\n>\n> I think the behavior you want is much more sensible.\n\nI think there's already confusion in this area, e.g., with @{...} using\nreflog dates, but \"git log --since\" using commit dates.  This can be an\neasy trap to fall into because _often_ the two have similar granularity\n(when you're mostly pushing changes), but not _always_ (when you pull a\nbig batch of changes).\n\nSoooo, being really really explicit about using reflog dates vs. commit\ndates -- and e.g., having option names like \"--since\" _always_ refer to\ncommit dates -- would be a good thing, I think...\n\n-Miles\n\n-- \nFuture, n. That period of time in which our affairs prosper, our friends\nare true and our happiness is assured.\n"},{"id":"179291","messageId":"4EBC157F.7040601@nextest.com","threadId":"28890","inReplyTo":"buok4785j8v.fsf@dhlpc061.dev.necel.com","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2011-11-10T18:18:39Z","receivedAt":"2011-11-10T18:18:39Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"On 11/10/2011 3:06 AM, Miles Bader wrote:\n> I think there's already confusion in this area, e.g., with @{...} using\n> reflog dates, but \"git log --since\" using commit dates.  This can be an\n> easy trap to fall into because _often_ the two have similar granularity\n> (when you're mostly pushing changes), but not _always_ (when you pull a\n> big batch of changes).\n> \n> Soooo, being really really explicit about using reflog dates vs. commit\n> dates -- and e.g., having option names like \"--since\" _always_ refer to\n> commit dates -- would be a good thing, I think...\n> \n> -Miles\n\nSurely you agree that my original example shows that the current behavior\nis confusing, yes?\n\nSo you're advocating --reflog-since (or some such)?\nOr to disable the early --since early exit when walking the reflog?\nOr for something else?\n\n- Eric\n"},{"id":"179345","messageId":"7v62iprg0b.fsf@alter.siamese.dyndns.org","threadId":"28890","inReplyTo":"20111109222032.GB31535@sigill.intra.peff.net","subject":"Re: RFH: unexpected reflog behavior with --since=","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-12T06:50:28Z","receivedAt":"2011-11-12T06:50:28Z","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> So I think the only decision is whether \"--since\" should respect the\n> commit timestamps (and be used as a sort of \"grep\" filter for\n> timestamps), or whether it should be respecting the fake history we\n> create when doing a reflog walk.\n>\n> I think I am leaning towards the latter.\n\nI tend to agree as far as the semantics go.\n\nAlso at least as a short term solution at the implementation level, I am\nOK with the change. But in the longer term, I have this suspicion that we\nshould not be rewriting commit objects themselves with these phony data,\nwhich makes things like \"git log -g --stat\" and \"git log --parents -g\"\ntotally useless.\n\nThat of course is not a fault of this patch; it does not make things any\nworse than the original, and that is why I say I am OK with it.\n\nThanks.\n"}]}