threads / discuss / 41509

reflog: weird options

Subject: reflog: weird options

## tl;dr

2 messages between Feb 25, 2016 and Feb 25, 2016.

replies: 1people: 2as markdown or json

David Turner· Feb 25, 2016, 00:00 UTC · lore

The manual for git reflog says it takes "[log-options]". And it does, sort-of. For instance, you can give a path, and it will only show you reflog entries that touch that path (I'm not sure why you would want to do that, but you can!). But you can also give --merges, which will silently give you no reflog entries. I don't know why.

One useful option that may or may not exist: show the time the reflog
entry was made.  I'd really like to say, "well, I know it was working
as-of last Tuesday...".  I know the data is in the reflog, but I don't
know how to show it.  I can show the committer date, which is usually
good enough when I'm rewriting a patch series, but that is not quite
the same thing.
 
I know I could fix these issues, but unfortunately I don't have the
time right now. It might make a good starter project for someone new to
git development!
Junio C Hamano· Feb 25, 2016, 00:49 UTC · re: David Turner · lore

Re: reflog: weird options

David Turner <dturner@twopensource.com> writes:
Show 16 quoted lines
> The manual for git reflog says it takes "[log-options]".  And it does,
> sort-of.  For instance, you can give a path, and it will only show you
> reflog entries that touch that path (I'm not sure why you would want to
> do that, but you can!).  But you can also give --merges, which will
> silently give you no reflog entries.  I don't know why.
>
> One useful option that may or may not exist: show the time the reflog
> entry was made.  I'd really like to say, "well, I know it was working
> as-of last Tuesday...".  I know the data is in the reflog, but I don't
> know how to show it.  I can show the committer date, which is usually
> good enough when I'm rewriting a patch series, but that is not quite
> the same thing.
>  
> I know I could fix these issues, but unfortunately I don't have the
> time right now. It might make a good starter project for someone new to
> git development!

I think somebody who is fairly new to the project was already looking into it. The hacky way the feature to show "reflog" entries was implemented (i.e. done by tweawking the "git log" machinery, even though the entries that comes out of the "log" and "reflog" are quite different things, as you observed by the lack of "time the reflog entry was created") shows up as these inconsistencies and "Huh?"s.

← back to recent threads