Re: git reflog --date

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

 



For me, writing "git reflog @{now}"  is a lot less intuitive than "git
reflog --date"

Currently the top google search for this question is here:

http://stackoverflow.com/questions/17369254/is-there-a-way-to-cause-git-reflog-to-show-a-date-alongside-each-entry

Which doesn't mention "@{now}"   at all.

My opinion:

1. Add --date   as an option to reflog.  Perhaps using the log.date
format as the default.
2. Document --date in the man page for "git reflog"
3. Document @{now}  in the man page for "git reflog"

Sound good?

John

On 21 October 2014 18:24, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> John Tapsell <johnflux@xxxxxxxxx> 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.
--
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]