Feature request for shorter relative date format in log

Feature request for shorter relative date format in log

[Yucheng Zhou]

Hello there,

I usually use --date=relative in git log, but I find it can be shorter to save more space and be more efficient. 

First, the trailing “ago” can be removed, because it seems every relative date has a trailing ago. 
Second, the seconds, minutes, hours, days, weeks, months, and years can be shorten to a single letter (e.g., s, m, h, d, w, M, Y), and the suffix “s” for plural can also be removed in this case. 
Maybe it will be better to give us a way to customize it, or create a new to config like --date=relative-short.

I apologize for any inconvenience since it’s my first time to use a mailing list.

Thanks.

Re: Feature request for shorter relative date format in log

[Taylor Blau]

On Wed, Aug 02, 2023 at 02:07:16PM +0800, Yucheng Zhou wrote:
> Hello there,
>
> I usually use --date=relative in git log, but I find it can be shorter
> to save more space and be more efficient.
>
> First, the trailing “ago” can be removed, because it seems every
> relative date has a trailing ago.  Second, the seconds, minutes,
> hours, days, weeks, months, and years can be shorten to a single
> letter (e.g., s, m, h, d, w, M, Y), and the suffix “s” for plural can
> also be removed in this case.  Maybe it will be better to give us a
> way to customize it, or create a new to config like
> --date=relative-short.

I can't think of a way that this is possible to do currently.

You can customize the format of absolute dates by using
`--date=format:xyz' where xyz is passed as an argument to the system's
strftime() implementation.

But we don't have a way for users to provide custom over relative dates.
Perhaps we should?

Thanks,
Taylor

Re: Feature request for shorter relative date format in log

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> But we don't have a way for users to provide custom over relative dates.

Are there existing systems to format time durations in a customized
way, just like strftime() is a way way to custom-format a timestamp,
that we can just use, or write our own modelling after them?

The relative-time code decides which points in the time durection
spectrum are good places to switch the granularity (e.g. up to 90
seconds we will give "N seconds", and up to 90 minutes we will give
"N minutes").  You could grep in date.c:show_date_relative() for
Q_() and _(), and place them in an array and allow them to be
replaced by strings in the configuration variable, but that will
cover only one smaller half of the problem (i.e. how the "N seconds"
are shown) and the other half (i.e. what variants there are, and
which variant is used for what time duration---you cannot introduce
a rule that says "up to 500 seconds, show 'N minutes M seconds'").

Even with that solution to the smaller half will also create i18n
headaches.

> Perhaps we should?

It will be an interesting puzzle, if done well.  Even though my
criteria to consider that a solution is done "well" is not that
high, it should at least allow defining your own variants.  Instead
of the rules that are implemented as hardcoded if-statement cascade
in date.c:show_date_relative(), it should allow you to say something
like

    * For a timestamp that is N seconds into the future, format a
      relative timestamp that is N seconds ago, and replace "ago"
      with "in the future".

    * For a timestamp that is less than 1200 seconds ago, show "N
      minutes M seconds ago" (with appropriate pluralization for
      "minute" and "second" when N and/or M is 1).

    * For a timestamp that is less than 5 hours ago, show "N hours M
      minutes ago" (ditto about plural).

and so on.

No, I am not interested in working on such a solution myself.  But
it will be an interesting puzzle.

Re: Feature request for shorter relative date format in log

[Yucheng Zhou]

Thank you for your reply!

Actually, I think there is no need to allow users to config the switching of granularity. The current relative format has already done a great job.
What I want is, a handy way to show a shorter relative date (like the “--short” flag in git status). And the current switching of granularity should be reused.

The only thing need to be changed, is the vocabulary for representation. For example, the “2 minutes ago” can be represented in “2m”, and “10 days ago” to “10d”. 
If both the past and future timestamps should be taken into account, we can use a prefix “-” and “+”  to distinguish them. But I think we hardly see a future timestamp in the git log output, so we can let the past timestamps un-prefixed and only prefix the future ones with a “+”, maybe.

The rationale of this feature is saving space in the output, to let more useful information be shown in one line.
For instance, many skilled git users use customized one-line formats in git log, such as “<hash> <date> <author> <title-line>”. Where the <date> can be shortened as much as possible to save space for other important things (especially using with --graph or --decorate). Therefore, a shorter relative date representation of no more than about 3 characters can be a great idea.

To achieve this, a new format like “relative-short” can be introduced. There is no need to let users config so many things. Since there already exists “--date=short” for short absolute date format and “--date=default-local” which consists of two words, I think a new option “--date=relative-short” with a well-designed shorter representation will be very handy and great.

Re: Feature request for shorter relative date format in log

[Taylor Blau]

On Wed, Aug 02, 2023 at 03:31:51PM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > But we don't have a way for users to provide custom over relative dates.
>
> Are there existing systems to format time durations in a customized
> way, just like strftime() is a way way to custom-format a timestamp,
> that we can just use, or write our own modelling after them?

I'm not aware of such a utility, no. I had imagined that we would
represent the duration between two timestamps as another timestamp
offset that same amount after the Epoch. Then the caller could specify a
strftime format string and format the "duration" that way.

> The relative-time code decides which points in the time durection
> spectrum are good places to switch the granularity (e.g. up to 90
> seconds we will give "N seconds", and up to 90 minutes we will give
> "N minutes").  You could grep in date.c:show_date_relative() for
> Q_() and _(), and place them in an array and allow them to be
> replaced by strings in the configuration variable, but that will
> cover only one smaller half of the problem (i.e. how the "N seconds"
> are shown) and the other half (i.e. what variants there are, and
> which variant is used for what time duration---you cannot introduce
> a rule that says "up to 500 seconds, show 'N minutes M seconds'").
>
> Even with that solution to the smaller half will also create i18n
> headaches.

Yeah, I think mangling with those translation identifiers is going to be
a giant mess.

> No, I am not interested in working on such a solution myself.  But
> it will be an interesting puzzle.

Ditto ;-).

Thanks,
Taylor