On 11/9/2011 2:01 PM, Jeff King wrote: > On Tue, Nov 08, 2011 at 04:22:41PM -0800, Eric Raible wrote: > > [explanation how --since is used to limits traversal omitted] Yes, all that is as expected, and makes sense. > Now let's look at reflog walking. It's kind of bolted on to the side > of the revision traversal machinery. We walk through the reflog > backwards and pretend that entry N's parent is entry N-1 (you can see > this if you do "git log -g -p", for example; you see the patch versus > the last reflog entry, not the patch against the commit's true parent). > > In the case of rewound history (like the reset you showed above), this > means that the history graph will appear to have bad clock skew. The > timestamp of HEAD@{0} is going to be much earlier than its pretend > parent, HEAD@{1}. And the "--since" optimization is going to cut off > traversal, even though there are more interesting commits to be shown. > > So in that sense, I think it's a bug, and we should probably disable the > exit-early-from-traversal optimization when we're walking reflogs. Indeed. Seems like a case of an optimization leading to an incorrect result. > But it may also be a misfeature, because it's not clear what you're > actually trying to limit by. We have commit timestamps, of course, but > when we are walking reflogs, we also have reflog timestamps. Did you > actually want to say "show me all commits in the reflog, in reverse > reflog order, omitting commits that happened before time t"? Or did you > really mean "show me the reflog entries that happened before time t, > regardless of their commit timestamp"? I meant "show me the reflog entries that happened *since* time t, regardless of their commit timestamp. > In the latter case, we would either need a new specifier (like > "--reflog-since"), or to rewrite the commit timestamp when we rewrite > the parent pointers. > > The latter has a certain elegance to it (we are making a pretend linear > history graph out of the reflog, so faking the timestamps to be sensible > and in order is a logical thing to do) but I worry about lying too much > in the output. Something like "git log -g --format=%cd" would now have > the fake timestamp in the output. But then, we already show the fake > parents in the output, so I don't know that this is any worse. Since -g is asking specifying for the reflog, and since the reflog has its own timestamps, I would expect that those timestamps be used. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html