Many changes and features

[cspotcode]

I've been making some really big changes. I don't know if you'll want to merge them, but here they are:

• Supports running multiple, parallel git invocations. Doesn't suffer from xargs issues.
• Full-featured option parsing with friendly usage information, --help, and --version
• Streaming input and output to avoid the maximum string size limitation
• Splits some fields into arrays (parent_hashes, ref_names)
• Supports legacy behavior, logging each repository within a directory, with the --directory or -d option

Other changes:

• Switches from Babel to TypeScript for transpilation. Anecdotally, TypeScript seems faster. Note that the code is all written in JavaScript, not TypeScript.
• Intelligently omits signature-related fields for unsigned commits
• Cross-platform; no more bash dependency.
• Outputs to stdout or to a file, controlled by --out or -o option.

[dreamyguy]

This is looking like a fine piece of programming, @cspotcode! I'm eager to merge, but I haven't had the time to test yet.

I think from now on I'm going to accept pull-requests on dedicated branches, so that I can resolve conflicts, update the README file accordingly and do a proper release, so that documentation and functionality go hand in hand. Can you create a pull-request to the javascript branch?

I'm going to dive into it and add the remaining fields:

• time_hour
• time_minutes
• time_seconds
• time_gmt
• date_day_week
• date_month_day
• date_month_name
• date_month_number
• date_year
• date_iso_8601

From there on only unicorns know! ✨ 🦄

[cspotcode]

Sounds good, I updated this PR to merge into javascript.

I can explain my reasons for simplifying the date fields. I think that the strict ISO 8601 dates are a good, universal format to include in the JSON output. In JavaScript they can be parsed with new Date(commit.author_date). Or you can use moment: moment(commit.author_date). From there you have an extensive API to parse out day, hour, perform timezone conversions, even compute human-friendly relative times. A single, strict ISO 8601 date string has everything you need.

I think the shortest, unqualified name for a given datetime field (for example author_date) should contain the strict ISO 8601 date. Other JSON fields, such as the ones you mentioned, can definitely be provided, but maybe they should be behind a CLI flag? For example --extra-datetime to include all the extra, parsed date and time fields or --no-extra-datetime to exclude them?

[telemenar]

Hi, I've got some additional changes that switch from using '--shortstat' to '--numstat' building on top of this.

They are in somewhat rough state right now, but is this something you'd appreciate me polishing up to build on top of this?

[dreamyguy]

This has surely waited too long, but after nearly a year it is here. I should have just have merged it back then. I'm going to keep this in a separate branch for now since even now I haven't gotten around to review anything yet.

I'd very much like to work further on this, but can only do so much at a time. Will hopefully be revisiting this project and its related ones soon - i.e. https://github.com/dreamyguy/gitlogg-api (API) and https://github.com/dreamyguy/gitinsight (Frontend).