Re: RFC: dynamic "auto" date formats

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

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> 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).

While I do not think this has much to do with "auto", other than
that it changes the representation depending on how far back the
time is to match the taste of Linus automatically, I think the
observation you made about the relative uselessness of "relative in
the long past" is real.  "6 years ago" that does not say if it was
in the morning and that does not even say if it was in the summer
is losing a bit too much information.

Your message made me realize another thing I feel while viewing
"relative in the long past" output.  In "git log --date=relative"
output (especially when the log is "limited" in some way, like with
a pathspec, --grep, -S, etc.) that shows multiple commits, all of
which are labeled "6 years ago", they make me wonder how they are
related to each other chronologically.  Perhaps I am seeing 6
commits, but the earlier four was made all within 20 minutes, and
the fifth one three days later, and the final one a month later,
which may indicate that the first four was the initial round of a
topic, with two "oops, this is a fix" follow-up patches that are
related in one area.  All of them being labeled "6 years ago" would
not give such a clue.

Which makes me wonder if another variant is useful (or at least
"interesting").  What if we chose format according to this rule?

    0. Set the "reference time" to the current time.

    1. Do get_revision() to grab one commit to show.

    2. Show that commit, using timeformat determined as:
       a. if its time is close to the "reference time", then use
          "N hours M minues before that" format;
       b. otherwise, use the default time format;

    3. Update the "reference time" to the timestamp of the commit
       we just showed.

    4. Go back to 1.
    
--
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]