On Sat, Jul 07 2018, Linus Torvalds wrote: I really like where this is going in general. Having a "human" format would be great. > For really recent dates (same day), use the relative date stamp, while > for old dates (year doesn't match), don't bother with time and timezone. > [...] > Once you're talking "last year" patches, you don't tend to care about time > of day or timezone. So the longest date is basically "Thu Oct 19 16:00", > because if you show the year (four characters), you don't show the time > (five characters). And the timezone (five characters) is only shown if not > showing the date (5-6 characters). Just chiming in on this part, I think it's a worthwile trade-off to always keep it relatively short, but I'd like to challenge the "you don't tend to care about time [for really old commits]". I think that's true for the likes of linux.git & git.git, but a lot of users of git say work in some corporate setting entirely or mostly in the same timezone. In that case, knowing if some commit whose sole message was "fix"[1] was made at 3am or in the afternoon, even if it's really old, is really useful information, even years later. Maybe something like v2 could be a human-lossy and v1 human-short (or better names...). I.e. (AFAICT) v1 didn't lose any information, just smartly abbreviated it, but v2 does. 1. Because let's face it, bothering to write good commit messages like git.git is the exception.
