Oops, forgot to add:

$  echo $SHELL
/bin/bash

$  bash --version | head -n1
GNU bash, version 5.1.8(1)-release (x86_64-redhat-linux-gnu)

$  scmpuff version
scmpuff 0.5.0

$  git --version
git version 2.35.1

$  which git
git ()
{
    case $1 in
        commit | blame | log | rebase | merge)
            scmpuff exec -- "$SCMPUFF_GIT_CMD" "$@"
        ;;
        checkout | diff | rm | reset | restore)
            scmpuff exec --relative -- "$SCMPUFF_GIT_CMD" "$@"
        ;;
        add)
            scmpuff exec -- "$SCMPUFF_GIT_CMD" "$@";
            scmpuff_status
        ;;
        *)
            "$SCMPUFF_GIT_CMD" "$@"
        ;;
    esac
}

Running on Fedora 35.

Ah interesting. This is an edge case that was never considered. I'm not sure if this is a generic way to handle this, so we'd have to special case all known single flag git arguments that can take an integer argument after a space. That requires keeping scmpuff in lockstep with potential git porcelain changes in the future, but I can't think of a way around that that would handle this edge case.

For git log alone, this will probably also affect --max-count=<number> and --skip=<number>, and --min-parents=<number>/--max-parents=<number>. In theory the double dash flags should require the = sign which wouldn't be an issue, but I'm willing to bet git does "forgiving" parsing rather than obeying the rules, and will permit dangling numbers on their own.

Sigh, yep, confirmed, it does...

Adding more and more test cases in #70 just for git log.

Git CLI is really inconsistent here. In short it's going to be a mess to special case everything.

Git does not (or at least the version on my laptop) to appear allow combining short flags, so we wouldn't have to deal with parsing git log -ign 1 versus git log -ing 1...

In contrast, git diff does allow combing short flags, and produces different results depending on the ordering. E.g. mutually exclusive flags -p and -s such that git diff -ps and git diff -sp produce different results (they appear to be processed in order, with the later overriding). Additionally git diff -U<number> does not allow the space before the numeric arg, unlike git log -n<number> which also accepts undocumented git log -n <number>.

And that's just what I've found on a quick glance... going to go for a walk and clear my head before thinking more of this. If the list of special cases and exceptions becomes large, it's going to be difficult to keep in sync with various versions of git CLI.

Ouch, I'd never really paid attention before to how inconsistent Git CLI is. Seems like this is going to be tricky 😬