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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
> 
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]