All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: John Tapsell <johnflux@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: git reflog --date
Date: Tue, 21 Oct 2014 10:24:34 -0700	[thread overview]
Message-ID: <xmqqh9yx1gkt.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAHQ6N+oQV8Uesv_eCBZc+hpwR5rDWA22OXR05AJ_zXcf7bfQ7g@mail.gmail.com> (John Tapsell's message of "Tue, 21 Oct 2014 09:11:50 +0100")

John Tapsell <johnflux@gmail.com> writes:

> Hi all,
>
>   Could we add a default to "--date" so that:
>
> git reflog --date
>
> just works?  (Currently you need to do:   git reflog --date=iso)  It
> should probably obey the default in log.date?

Hmph.  "--date=<style>" is not the way to choose between timed and
counted output in the first place, though.

In a similar way that "git log -g @{now}" and "git log -g @{0}"
switch between two, "git reflog @{now}" and "git reflog @{0}" have
been the primary way to choose between them.  Only because it is
clear that you want the timed format when you specify any date style
e.g. "git reflog --date=relative", we give timed output without
@{<time>/<number>} but that is just icing on the cake.

That at least is why things are the way they are.  And once you
understand the above, you would understand why "--date=<style>" is
not singled out as a useful option in the documentation, because
that is not a primary way to choose between timed and counted
output, but because it is merely a way to influence how times are
shown once you chose timed output.

Having said all that, I have a few comments:

 - Perhaps use of @{<time>} vs @{<count>} as _the_ way to choose
   between timed and counted output is not documented clearly enough
   to lead to such a misunderstanding?

 - Perhaps use of @{<time>} vs @{<count>} is a less intuitive than
   ideal way to choose between them in the first place?

 - Perhaps adding --date with no date-style specification as another
   way to trigger "You said 'date' so you must mean you want timed
   output" heuristics just like existing "--date=<style>" does may
   let us get away without answering the above two questions,
   sidestepping the issues?

I dunno.

  reply	other threads:[~2014-10-21 17:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21  8:11 git reflog --date John Tapsell
2014-10-21 17:24 ` Junio C Hamano [this message]
2014-10-21 17:31   ` John Tapsell
2014-10-21 18:06     ` Junio C Hamano
2014-10-21 18:12       ` John Tapsell
2014-10-21 23:11         ` Junio C Hamano
2014-10-21 22:21       ` Junio C Hamano
2014-11-04 17:06   ` Phil Hord
2020-08-12  0:28 Craig H Maynard
2020-08-12  9:14 ` Jeff King
2020-08-12 12:34   ` Craig H Maynard

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=xmqqh9yx1gkt.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=johnflux@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.