API for +log views

[GoogleCodeExporter]

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

Original issue reported on code.google.com by dborowitz@google.com on 11 Apr 2013 at 7:29

[GoogleCodeExporter]

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.

Original comment by szager@chromium.org on 26 Sep 2013 at 5:43

[GoogleCodeExporter]

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?

Original comment by aval...@chromium.org on 22 Oct 2013 at 2:35

[GoogleCodeExporter]

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.

Original comment by bens...@google.com on 22 Oct 2013 at 2:39

[GoogleCodeExporter]

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

Original comment by bens...@google.com on 22 Oct 2013 at 2:41

[GoogleCodeExporter]

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

Original comment by mdemp...@google.com on 31 Oct 2013 at 5:41

[GoogleCodeExporter]

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.

Original comment by dborowitz@google.com on 1 Nov 2013 at 7:17

[GoogleCodeExporter]

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.)

Original comment by mdemp...@google.com on 1 Nov 2013 at 7:38

[GoogleCodeExporter]

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

Original comment by dborowitz@google.com on 1 Nov 2013 at 7:44

[GoogleCodeExporter]

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

Original comment by bens...@google.com on 2 Nov 2013 at 12:46

[GoogleCodeExporter]

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.

Original comment by dborowitz@google.com on 4 Nov 2013 at 7:01

[GoogleCodeExporter]

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.

Original comment by bens...@google.com on 4 Nov 2013 at 8:13

[GoogleCodeExporter]

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

Original comment by mdemp...@google.com on 4 Nov 2013 at 8:14

[GoogleCodeExporter]

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.

Original comment by sop@google.com on 4 Nov 2013 at 8:28