Feature request for shorter relative date format in log

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.

On Wed, Aug 02, 2023 at 02:07:16PM +0800, Yucheng Zhou wrote:

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

Taylor Blau <me@ttaylorr.com> writes:

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.

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.

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.

On Wed, Aug 02, 2023 at 03:31:51PM -0700, Junio C Hamano wrote:

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.

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

Ditto ;-).

Thanks, Taylor