git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: RFH: unexpected reflog behavior with --since=

From
EREric Raible <raible@nextest.com>
Date
Nov 10, 2011, 08:04 UTC
Message-ID
<4EBB8596.6040507@nextest.com>
In-Reply-To
<20111109222032.GB31535@sigill.intra.peff.net>
On 11/9/2011 2:20 PM, Jeff King wrote:
Show 5 quoted lines
> On Wed, Nov 09, 2011 at 05:01:28PM -0500, Jeff King wrote:
> 
> This patch (which is below) turns out to be absurdly simple. And it
> actually still prints the original commit timestamp, because we end up
> reparsing it out of the commit object during the pretty-print phase.
Sweet!
> So I think the only decision is whether "--since" should respect the
> commit timestamps (and be used as a sort of "grep" filter for
> timestamps), or whether it should be respecting the fake history we
> create when doing a reflog walk.

When -g is specified it seems less surprising for --since to respect the reflog's fake history. That's what *I* expected, anyway.

Show 8 quoted lines
> I think I am leaning towards the latter. It seems to me to be the more
> likely guess for what the user would want. And there is real benefit to
> doing it in git, since we can stop the traversal early. In the
> "grep-like" case, doing it inside git is not really any more efficient
> than filtering in a pipeline, like:
> 
>   git log -g --format='%ct %H' |
>   awk '{ print $2 if $1 < SOME_TIMESTAMP }'
And then the sha would have to be fed back into git to be useful, eh?
> Of course we could still offer both (with a "--reflog-since" type of
> option). We'd also need to turn off the optimization for "--since", and
> then check whether "--until" has a similar bug (and offer
> "--reflog-until").
I don't see the point of --reflog-since.  If the user specifies 'reflog'
(either directly or with -g), then can't we just use the reflog's timestamp?
Note: there might be good reasons, as my use of the reflog (and --since, for
that matter), has been very simplistic so far.
Show 12 quoted lines
> diff --git a/reflog-walk.c b/reflog-walk.c
> index 5d81d39..2e5b270 100644
> --- a/reflog-walk.c
> +++ b/reflog-walk.c
> @@ -231,6 +231,7 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
>  	reflog = &commit_reflog->reflogs->items[commit_reflog->recno];
>  	info->last_commit_reflog = commit_reflog;
>  	commit_reflog->recno--;
> +	commit->date = reflog->timestamp;
>  	commit_info->commit = (struct commit *)parse_object(reflog->osha1);
>  	if (!commit_info->commit) {
>  		commit->parents = NULL;

Is this something you'd be willing to turn into a real patch? I'm certainly not qualified.

Thanks - Eric
Previous: Jeff KingNext: Jeff King
Message 5 of 13 in “RFH: unexpected reflog behavior with --since=”
  1. Eric RaibleNov 9, 2011
  2. Jeff KingNov 9, 2011
  3. Jeff KingNov 9, 2011
  4. Jeff KingNov 9, 2011
  5. Eric RaibleNov 10, 2011
  6. Jeff KingNov 10, 2011
  7. Eric RaibleNov 10, 2011
  8. Jay SoffianNov 10, 2011
  9. Miles BaderNov 10, 2011
  10. Eric RaibleNov 10, 2011
  11. Junio C HamanoNov 12, 2011
  12. Eric RaibleNov 10, 2011
  13. Jeff KingNov 10, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.