Re: [PATCH] pretty format string support for reflog times

2 messages, 2 authors, 2016-07-27 · open the first message on its own page

Re: [PATCH] pretty format string support for reflog times

From: Junio C Hamano <hidden>
Date: 2016-07-27 17:18:19

Jeff King [off-list ref] writes:
On Wed, Jul 27, 2016 at 04:14:14AM -0400, Phil Pennock wrote:
quoted
The reflog contains timestamp information, but these were not exposed to
`--pretty`.  Four of the six author/committer format string
second-letters were still available and copied, but `d`/`D` are taken
for reflog selector formatting.  So use `%gT` for "time" instead of
"date" mnemonic for using `--date=...` formatting.
Hrm. Since Ted was not cc'd, it is not clear to me whether this is
coincidental or in response to the thread over in

  http://thread.gmane.org/gmane.comp.version-control.git/299201

To summarize, I think the conclusion there was that we would go with at
least the 't' and 'r' formatters in the short term. The 'i/I' ones were
not something Ted cared about that much, I think, but they do make
things orthogonal with the other ident dates.
I forgot about that thread after it stalled without drawing
conclusion, after Ted asked if anybody has a strong opinion
and saw only one response to it at

  https://public-inbox.org/git/20160711164317.GB3890%40thunk.org/

So, what is the next step?  Apply

  https://public-inbox.org/git/20160710055402.32684-1-tytso%40mit.edu/

but exclude %g[iI] bits out of that patch while doing so?

Thanks.

Re: [PATCH] pretty format string support for reflog times

From: Jeff King <hidden>
Date: 2016-07-27 17:39:22

On Wed, Jul 27, 2016 at 10:18:11AM -0700, Junio C Hamano wrote:
quoted
Hrm. Since Ted was not cc'd, it is not clear to me whether this is
coincidental or in response to the thread over in

  http://thread.gmane.org/gmane.comp.version-control.git/299201

To summarize, I think the conclusion there was that we would go with at
least the 't' and 'r' formatters in the short term. The 'i/I' ones were
not something Ted cared about that much, I think, but they do make
things orthogonal with the other ident dates.
I forgot about that thread after it stalled without drawing
conclusion, after Ted asked if anybody has a strong opinion
and saw only one response to it at

  https://public-inbox.org/git/20160711164317.GB3890%40thunk.org/

So, what is the next step?  Apply

  https://public-inbox.org/git/20160710055402.32684-1-tytso%40mit.edu/

but exclude %g[iI] bits out of that patch while doing so?
After having thought about it, I'm inclined to leave in the "%gi".
There's no real rationale for doing "%gr" and "%gt" and not "%gi" except
"well, Ted didn't need it". And it does make it match the author and
committer date-formatting (except for the 'd' formats, of course).

I do think with the new "unix" format in jk/reflog-date, the interface
to the reflog code could be simplified; we don't need a function to pull
out just the timestamp any more. Something like the diff below.

However, I see a few remaining issues with Ted's original:

  - the refactored get_reflog_message() tries to return NULL, but the
    return type of the function is void. Presumably this should just be
    "return"?

  - ditto, the new get_reflog_time_t returns NULL, but wants an unsigned
    long (though this function goes away with my squash below)

  - show_reflog_date can return NULL, but we blindly feed its return
    value to strbuf_addstr(). I'm not sure under what conditions it
    _would_ return NULL, but that would cause a segfault

  - there should probably be tests in t6006 for the new formats

  - my squash below cuts out the use of gm_time_t(). But I don't think
    it should be necessary, as the reflog timestamp should already be in
    GMT, I would think. But maybe I am missing something.

I actually think Phil's patch from today is a little cleaner for most of
these, as it returns the values via out-parameters, and uses the return
value for "did we get anything?".

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help