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 <gits...@pobox.com> wrote:
> John Tapsell <johnf...@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
