API for +log views about gitiles HOT 15 CLOSED

-Support JSON/TEXT format for +log
-Support additional arguments similar to git log, e.g. filtering by author or date.

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.