On Sun, Dec 30, 2018 at 05:31:48PM -0700, Stephen P. Smith wrote:
> Also add 'auto' date mode, which defaults to human if we're using the
> pager. So you can do
>
> git config --add log.date auto
>
> and your "git log" commands will show the human-legible format unless
> you're scripting things.
I like the idea of "human", and I like the idea of "auto", but it seems
to me that these are really two orthogonal things. E.g., might some
people not want to do something like:
git config log.date auto:relative
?
I don't personally care about using this myself, but we already had to
deal with retrofitting "local" as a modifier. I'd prefer to avoid making
the same mistake again.
(I'd actually argue that "log.date" should basically _always_ have the
"auto" behavior, since it tends to get treated as plumbing anyway, and I
suspect that anybody who sets log.date now would see subtle breakage
from scripts. But maybe it's too late at this point?).
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 6d798f9939..f684e31d82 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -925,6 +925,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
> */
> blame_date_width = utf8_strwidth(_("4 years, 11 months ago")) + 1; /* add the null */
> break;
> + case DATE_HUMAN:
> + /* If the year is shown, no time is shown */
> + blame_date_width = sizeof("Thu Oct 19 16:00");
> + break;
OK, and we expect the year to be less than 5 characters. I briefly
wondered what would happen at Y100K (or somebody maliciously using a
bogus year), but it is not a buffer overflow. It is simply a mis-aligned
blame line (and actually, the same goes for the existing entries, which
use a 4-digit year).
-Peff
