git-quick-stats -j does not work as expected

[arzzen]

git-quick-stats -j does not work as expected

[tomice]

The JSON option is experimental and is not an option you can easily customize like the others. It doesn't have the ability to understand the logic that is going on within the other functions. The only parameters that can be altered are $_GIT_SINCE, $_GIT_UNTIL, and $_GIT_MERGE_VIEW.

I cannot pass the path as an argument

This is correct. It goes into an interactive mode asking where you'd like the path to be stored. That is why you are seeing INVALID ARGUMENT at the top. You are not sending it a valid argument in this case.

The option does not compose well

Unfortunately, this option cannot be used with other options

When passing the argument interactively it still does not work

The path given to it must be an absolute path. In this instance, you're writing your file to /git-stats.json, not $(pwd)/git-stats.json

I can attempt to update the documentation to show that this is a basic and experimental feature this weekend.

[fredericcogny]

Thanks for reverting so quickly.

I've seen the docs you've added in 891e227 and it definitely makes it clearer.

I believe however that, beside the composition which is indeed not simple given the current implementation, the other two points should not be that hard to fix.

you could, for instance, support the two-argument cases with

if [[ "$#" -eq 2 ]]; then
  case "$1" in
    -R|--git-stats-by-branch)
        branch="$2"
        detailedGitStats "${branch}";;
    -L|--changelogs-by-author)
        author="$2"
        changelogs "${author}";;
    -A|--commits-by-author-by-hour)
        author="$2"
        commitsByHour "${author}";;
    -j|--json-output)
        json_path="$2"
        jsonOutput "$json_path";;
    *) echo "Invalid argument"; usage; exit 1;;
    esac
fi

[[ "$#" -gt 2 ]] && { echo "Invalid arguments"; usage; exit 1; }

and then modify jsonOutput to directly take the input path

################################################################################
# DESC: Saves the git log output in a JSON format
# ARGS: $json_path (required): Path to where the file is saved
# OUTS: A JSON formatted file
################################################################################
function jsonOutput() {
    optionPicked "Output log saved to file at: $json_path"
    git -c log.showSignature=false log --use-mailmap $_merges $_since $_until \
        --pretty=format:'{%n  "commit": "%H",%n  "abbreviated_commit": "%h",%n  "tree": "%T",%n  "abbreviated_tree": "%t",%n  "parent": "%P",%n  "abbreviated_parent": "%p",%n  "refs": "%D",%n  "encoding": "%e",%n  "subject": "%s",%n  "sanitized_subject_line": "%f",%n  "body": "%b",%n  "commit_notes": "%N",%n  "author": {%n    "name": "%aN",%n    "email": "%aE",%n    "date": "%aD"%n  },%n  "commiter": {%n    "name": "%cN",%n    "email": "%cE",%n    "date": "%cD"%n  }%n},' \
        | sed "$ s/,$//" \
        | sed ':a;N;$!ba;s/\r\n\([^{]\)/\\n\1/g' \
        | awk 'BEGIN { print("[") } { print($0) } END { print("]") }' \
        > "$json_path"
}

this way I believe it would work with both absolute and relative paths

This is however untested and might be completely wrong. I have very little bash experience so pardon me if this actually makes little sense

[tomice]

The parameter passing part isn't necessary hard. It can be done relatively easily with another argument like you are explaining. However, sanitizing strings in bash across multiple languages on multiple platforms with different possible versions (see OS X's deprecated bash, for instance) can be difficult.

The other thing is that we currently have a somewhat unified interface in which we handle a secondary argument. Take the --git-stats-by-branch option. It can take a branch, but it is only able to take it interactively. --commits-by-author and --commits-by-author-by-hour follow the same style, too.

By having the JSON one have its own special positional argument, as well as be able to adjust its output as requested in this original issue ticket (i.e. combining --commits-by-author and having it output as JSON), it starts to create this issue where everything needs to handle JSON.

At that point, we need to take a look at the JSON option itself because our JSON option is becoming a first class citizen instead of a quick feature that was developed. If we want such a rewrite to be able to handle JSON composition for all of our options, then the JSON output should be a robust implementation, and it unfortunately is not.

There are quite a few cases where the JSON parsing can break and output non-valid JSON, and that's the real reason why this is in beta. Bash doesn't have the ability to handle strings like Python, or even Perl, can, but if we were to leverage those languages for JSON, then we are breaking the spirit of this program. Git commits are notoriously hard to sanitize and output as valid JSON, and that is the true reason why this hasn't been expanded on too much.

That said, I'm more than willing to hear opinions from others regarding this, as well as reviewing code that implements extended JSON functionality. :)