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 18:09:37

Jeff King [off-list ref] writes:
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?".
True.  That part of the interface is indeed better done with the new
one.

I am still in favor of this suggestion you earlier made:
So the final solution is more like:

  - a formatter for just the reflog time, respecting date

  - a formatter for just the reflog index (the "0" in HEAD@{0})

  - a formatter for the ref name (just the "HEAD" in HEAD@{0})
though.  After all we only need three short ones while we migrate
away to a longer %(reflog:<what>) format, right?

As to the unfortunate %gd that squats on the "date" other specifiers
use, I do not see a good/quick approach to migrate it.  If our ideal
short-term endgame before the longer format were to use %gd, %g# and
%gg for the above three, we first start warning people who use %gd
for the historical mistaken "reflog selector", while telling people
to use "%gg@{%g#}" instead if they truly want "reflog selector", and
then switch its meaning to "reflog date".  That would take a long
time.

As %r prefix is not taken, we can immediately deprecate %g-anything
format as a historical mistake and make sure we do not repeat the
mistake of giving "d" to "reflog selector", perhaps?

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

From: Jeff King <hidden>
Date: 2016-07-27 18:17:32

On Wed, Jul 27, 2016 at 11:09:30AM -0700, Junio C Hamano wrote:
I am still in favor of this suggestion you earlier made:
quoted
So the final solution is more like:

  - a formatter for just the reflog time, respecting date

  - a formatter for just the reflog index (the "0" in HEAD@{0})

  - a formatter for the ref name (just the "HEAD" in HEAD@{0})
though.  After all we only need three short ones while we migrate
away to a longer %(reflog:<what>) format, right?
Yes, I think those three would be sufficient to allow something like:

  HEAD@{0} (1 month ago) ...

where the relative time would come from "%gT" mixed with
"--date=relative". What that doesn't allow is showing the time in
multiple formats with different placeholders, like:

  HEAD@{0} (2016-06-25T01:23:45 -- 1 month ago) ...

For that you need either format-specific placeholders, or a generic date
placeholder which can specify the format, like:

  %(reflog-date:relative)

So if you mean doing those on _top_ of what Phil and Ted are proposing,
I think it is pretty flexible, but just a bit ugly. But doing it
_instead_ would not allow the format Ted wanted.
As to the unfortunate %gd that squats on the "date" other specifiers
use, I do not see a good/quick approach to migrate it.  If our ideal
short-term endgame before the longer format were to use %gd, %g# and
%gg for the above three, we first start warning people who use %gd
for the historical mistaken "reflog selector", while telling people
to use "%gg@{%g#}" instead if they truly want "reflog selector", and
then switch its meaning to "reflog date".  That would take a long
time.
I don't think it's worth the deprecation effort and confusion.
As %r prefix is not taken, we can immediately deprecate %g-anything
format as a historical mistake and make sure we do not repeat the
mistake of giving "d" to "reflog selector", perhaps?
Moving to "%r" as a more sensible prefix for "reflog", while cleaning up
historical mistakes, is more appealing. But if we really are planning to
move to "%(reflog-*)", then I think we can just forget about "%r"
entirely.

I just don't think anybody has volunteered to work on %(reflog).

-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