# reflog: weird options 2 messages from 2016-02-25 to 2016-02-25. Participants: David Turner, Junio C Hamano. Thread: https://gitlist.dev/t/41509 ## David Turner, 2016-02-25 00:00 Subject: reflog: weird options Message-ID: <1456358433.18017.35.camel@twopensource.com> URL: https://gitlist.dev/e/1456358433.18017.35.camel%40twopensource.com ``` 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, 2016-02-25 00:49 Subject: Re: reflog: weird options Message-ID: URL: https://gitlist.dev/e/xmqqbn75r4vs.fsf%40gitster.mtv.corp.google.com In-Reply-To: <1456358433.18017.35.camel@twopensource.com> ``` David Turner writes: > 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. ```