Refactor gitlogg-generate-log.sh

[jamesbrink]

Refactor cleanup steps between git log output and json parser
This specifically resolved an issue with processing git commits
that had been reverted and lacked any short stats in output.

I was running into issues running this on 42 private repos. Out of the 42, two were failing and it turned out they both had reverted commits with no file stats. Although there was logic in place to handle this case, it was not working properly for me at all. I was experiencing the issues mentioned in #7.

The commits would essentially get collapsed incorrectly by the existing process and through off the rest of the log.

I have tested my changes against a total of 150 repos without any further issues. For the record I am running Arch Linux, so I have not tested these changes on macOS.

[dreamyguy]

Hi @jamesbrink, thanks for taking the time to improve Gitlogg, much appreciated! 🙌

If I understood you correctly, the fix here is for reverted commits with no modifications. I remember handling commits with no stats before, the first time I brought it in was 3 years ago: 11a50b2#diff-1994233f808acc8c71502e62d14a6662R32. The current change is still the same, with a rare character replacing the § one, a poor choice at the time. Still... there could be something awry with it as it is right now.

The initial version of Gitlogg was indeed just a shell script, but many things were brought in since then; some error handling and special fields, that are based on the log itself but require some calculations: https://github.com/dreamyguy/gitlogg/blob/master/scripts/gitlogg-parse-json.js#L138-L154.

I'm thinking to keep your changes in a dedicated branch, or simply as this PR, since they take away a lot of what me and others still depend on. I think the next big improvement here is validation at runtime, so we fail early if there's an error.

Check out the javascript branch, a tremendous effort done by someone else, that has a lot of type validation at runtime. 🙂