API for +log views about gitiles HOT 14 OPEN

It would also be nice to have a rev-list endpoint.  There are a lot of services 
that will only be interested in the ordering of commits.

I'd be willing to patch in the json support. Which fields were you interested 
in having in the output? Are you looking at KeySet.SHORTLOG just like in the 
html output?

from https://skia.googlesource.com/skia/+log/HEAD

I'd like to get the full git hash and associated commit time in unix seconds 
for each row. Thanks.

Are CL descriptions and authors too much to add? If not, we might need them in 
the future. Thank you.

FWIW, gwt-team is interested in at least commit hash id, subject, author name, 
and author email.

First pass at:
https://gerrit-review.googlesource.com/51324

Only supports the limit revision syntax already supported by +log; will 
eventually be extended to have more git-rev-list-y options.

dborowitz: That looks great!  Will log entries still be listed newest to oldest 
like in the current view?

Tangentially, does +log have anything similar to git log's --reverse and/or 
--max-count options?  (In my use case, I'd ideally be able to query the 
equivalent of "git log -5 --reverse $COMMIT..HEAD", but generally $COMMIT is 
only a couple revisions behind HEAD anyway, so in practice it's fine that I 
reverse and truncate the results myself.)

Ordering is the same as the HTML view of +log. No --reverse yet, that's in the 
category of "more git-rev-list-y options".

The following change adds "n" as a limit parameter:
https://gerrit-review.googlesource.com/51325

So "time" is not in Unix seconds, which means we still need to parse for 
calculations.

Sure, but the string should be parseable by strptime(3), right? I stuck with 
the form produced by git log, and also I prefer my JSON to be human-readable. 
But if this is an impediment to scripts working I am open to alternatives.

I'll then parse the string in Java and Python to get unix time - thanks for the 
explanation. It is nice to make it human-readable and let machines do the hard 
work.

Doesn't matter to me, but why not provide both the human readable output and a 
seconds-since-the-epoch count?

UNIX time in JSON is ugly. I much prefer a human readable time that is parsed 
by machine using a known format. Gerrit's JSON feeds use ISO format "yyyy-mm-dd 
hh:mm:ss.mmm" in UTC and demands clients to parse and reformat in their desired 
timezone.

I also don't like the idea of presenting the same data twice in different 
formats, it leaves room for errors like one field being filled in and the other 
not, etc. Much better to have just one field in a well defined format. A human 
readable time is easy for a human to write a parser around, they can see what 
the format is, configure their time parsing library function to read it, and 
move on.

+1 to more filtering options, like --before/after.