git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Stephen P. Smith" <ischis2@cox.net>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH 1/3] Add 'human' date format
Date: Thu, 03 Jan 2019 06:19:56 -0700	[thread overview]
Message-ID: <2637944.PqRbksyA0G@thunderbird> (raw)
In-Reply-To: <20190103073735.GB24925@sigill.intra.peff.net>

On Thursday, January 3, 2019 12:37:35 AM MST Jeff King wrote:
> 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 didn't see anything in the code which would prohibit setting something like 
that.  

> 
> 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.
Since I wasn't involved could you summarize the you are referring to?

> 
> (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?).
If auto isn't added to the "log.date" file, then the date behaviour is not 
changed from is currently in the code base.   Therefore, there shouldn't be 
any breakage.
> 
> > 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





  reply	other threads:[~2019-01-03 13:19 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-31  0:31 [PATCH 0/3] Add 'human' date format Stephen P. Smith
2018-12-31  0:31 ` [PATCH 1/3] " Stephen P. Smith
2019-01-03  7:37   ` Jeff King
2019-01-03 13:19     ` Stephen P. Smith [this message]
2019-01-04  7:50       ` Jeff King
2019-01-04 13:03         ` Stephen P Smith
2019-01-06  6:19           ` Jeff King
2018-12-31  0:31 ` [PATCH 2/3] Add 'human' date format documentation Stephen P. Smith
2018-12-31  0:31 ` [PATCH 3/3] t0006-date.sh: add `human` date format tests Stephen P. Smith
2019-01-02 18:15   ` Junio C Hamano
2019-01-03  2:36     ` Stephen & Linda Smith
2019-01-03  6:42       ` Junio C Hamano
2019-01-03 13:20         ` Stephen P. Smith
2019-01-03 21:14     ` Philip Oakley
2019-01-03 21:45       ` Junio C Hamano
2019-01-03 23:57         ` Stephen P. Smith
2019-01-03  7:44   ` Jeff King
2019-01-03 13:12     ` Stephen & Linda Smith
2019-01-08 21:27   ` Johannes Sixt
2019-01-09  0:44     ` Stephen P. Smith
2019-01-09  6:58       ` Johannes Sixt
2019-01-10  1:50         ` Stephen & Linda Smith
2019-01-18  6:18 ` [PATCH v2 0/5] Re-roll of 'human' date format patch set Stephen P. Smith
2019-01-18  6:18   ` [PATCH v2 1/5] Add 'human' date format Stephen P. Smith
2019-01-18  6:18   ` [PATCH v2 2/5] Remove the proposed use of auto as secondary way to specify human Stephen P. Smith
2019-01-18 18:35     ` Junio C Hamano
2019-01-19  3:44       ` Stephen & Linda Smith
2019-01-18  6:18   ` [PATCH v2 3/5] Add 'human' date format documentation Stephen P. Smith
2019-01-18 18:47     ` Junio C Hamano
2019-01-18  6:18   ` [PATCH v2 4/5] Add `human` format to test-tool Stephen P. Smith
2019-01-18 19:03     ` Junio C Hamano
2019-01-20 22:11       ` Stephen P. Smith
2019-01-22 18:29         ` Junio C Hamano
2019-01-18  6:18   ` [PATCH v2 5/5] Add `human` date format tests Stephen P. Smith
2019-01-18 19:24     ` Junio C Hamano
2019-01-21  5:31   ` [PATCH v3 0/5] Re-roll of 'human' date format patch set Stephen P. Smith
2019-01-21  5:31     ` [PATCH v3 1/5] Add 'human' date format Stephen P. Smith
2019-01-21  5:31     ` [PATCH v3 2/5] Replace the proposed 'auto' mode with 'auto:' Stephen P. Smith
2019-01-21  5:31     ` [PATCH v3 3/5] Add 'human' date format documentation Stephen P. Smith
2019-01-21  5:31     ` [PATCH v3 4/5] Add `human` format to test-tool Stephen P. Smith
2019-01-22 22:34       ` Junio C Hamano
2019-01-21  5:31     ` [PATCH v3 5/5] Add `human` date format tests Stephen P. Smith
2019-01-29  3:50     ` [PATCH v4 0/5] Re-roll of 'human' date format patch set Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 1/5] Add 'human' date format Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 2/5] Replace the proposed 'auto' mode with 'auto:' Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 3/5] Add 'human' date format documentation Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 4/5] Add `human` format to test-tool Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 5/5] Add `human` date format tests Stephen P. Smith
2019-01-21  5:16 ` [PATCH v3 0/5] Re-roll of 'human' date format patch set Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 1/5] Add 'human' date format Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 2/5] Replace the proposed 'auto' mode with 'auto:' Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 3/5] Add 'human' date format documentation Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 4/5] Add `human` format to test-tool Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 5/5] Add `human` date format tests Stephen P. Smith
2019-01-21 15:04     ` SZEDER Gábor
2019-01-22  0:53       ` Stephen & Linda Smith

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=2637944.PqRbksyA0G@thunderbird \
    --to=ischis2@cox.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=torvalds@linux-foundation.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).