git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: RFC: dynamic "auto" date formats
Date: Thu, 26 May 2016 20:36:57 -0700	[thread overview]
Message-ID: <CA+55aFzWEf2sN647v0mfiPOFE=KindQpweoHwdPmDshUb0YVsA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

This is a throw-away idea with a simple patch attached, which I don't
think anybody should really take all that seriously per se, but I
thought I'd throw it out and see if it generates any discussion.

I almost never use anything but the default date format (DATE_NORMAL),
but every once in a while I will use "--date=relative", typically
because I'm looking at my own commits and I'm just checking when I did
something.

It struck me that I've made the default for most of the logging things
be that when I'm just browsing with the pager, git will automatically
do the right thing. So I have

  [color]
      ui=auto

  [log]
      decorate = auto

in my ~/.gitconfig, and it shows me all those other things I tench to
want to know (like "thar's what I've pushed out" thanks to
decorations).

So I started thinking about when I care about dates, and decided that
maybe I can have a "--date=auto" too. It basically uses relative date
formats for the last 24 hours, and then switches over to the default
format.

I've used it a bit, and like Katy Perry said, I think I might like it.

Note that this doesn't add any gitconfig setting to do this, which
would be part of the whole point if this is actually sensible. But I'm
not entirely convinced it's worth it in the first place, thus this
email to see how people react ("That's just stupid" vs "yeah, I didn't
even know I wanted it, but now I need it").

And no, I'm not at all sure that the 24-hour cut-off is the right
thing, but it didn't seem completely crazy either. I tend to like the
relative date format when it is "19 minutes ago" vs "2 hours ago", at
some point it's long enough ago that it's more useful to know "Tuesday
at 3pm" than about how long ago it was.

(And yes, it would be even better to have the "short term relative
date" turn into a "medium-term 'day of the week at time x'" and then
turn into "full date" when it's more than a week ago, but this patch
only has the two modes of "short term" and "long term" and nothing in
between).

               Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 1787 bytes --]

 builtin/blame.c |  1 +
 cache.h         |  3 ++-
 date.c          | 10 +++++++---
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/builtin/blame.c b/builtin/blame.c
index 21f42b0b62b8..4d87181dc6cd 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2640,6 +2640,7 @@ parse_done:
 		   fewer display columns. */
 		blame_date_width = utf8_strwidth(_("4 years, 11 months ago")) + 1; /* add the null */
 		break;
+	case DATE_AUTO:
 	case DATE_NORMAL:
 		blame_date_width = sizeof("Thu Oct 19 16:00:04 2006 -0700");
 		break;
diff --git a/cache.h b/cache.h
index 6049f8671138..624817c20414 100644
--- a/cache.h
+++ b/cache.h
@@ -1223,7 +1223,8 @@ struct date_mode {
 		DATE_ISO8601_STRICT,
 		DATE_RFC2822,
 		DATE_STRFTIME,
-		DATE_RAW
+		DATE_RAW,
+		DATE_AUTO,
 	} type;
 	const char *strftime_fmt;
 	int local;
diff --git a/date.c b/date.c
index 7c9f76998ac7..c38414a3d968 100644
--- a/date.c
+++ b/date.c
@@ -184,13 +184,15 @@ const char *show_date(unsigned long time, int tz, const struct date_mode *mode)
 		return timebuf.buf;
 	}
 
-	if (mode->type == DATE_RELATIVE) {
+	if (mode->type == DATE_RELATIVE || mode->type == DATE_AUTO) {
 		struct timeval now;
 
 		strbuf_reset(&timebuf);
 		gettimeofday(&now, NULL);
-		show_date_relative(time, tz, &now, &timebuf);
-		return timebuf.buf;
+		if (mode->type != DATE_AUTO || time + 24*60*60 > now.tv_sec) {
+			show_date_relative(time, tz, &now, &timebuf);
+			return timebuf.buf;
+		}
 	}
 
 	tm = time_to_tm(time, tz);
@@ -792,6 +794,8 @@ static enum date_mode_type parse_date_type(const char *format, const char **end)
 		return DATE_RAW;
 	if (skip_prefix(format, "format", end))
 		return DATE_STRFTIME;
+	if (skip_prefix(format, "auto", end))
+		return DATE_AUTO;
 
 	die("unknown date format %s", format);
 }

             reply	other threads:[~2016-05-27  3:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-27  3:36 Linus Torvalds [this message]
2016-05-27  4:00 ` RFC: dynamic "auto" date formats Jeff King
2016-05-27  6:21 ` Junio C Hamano
     [not found]   ` <CA+55aFwhUJ2g9690yMBR3inZmVXRupmgjbePmm4GC5kEcx2XLA@mail.gmail.com>
2016-05-27  6:57     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+55aFzWEf2sN647v0mfiPOFE=KindQpweoHwdPmDshUb0YVsA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).