sort git diff --stat by total number of lines changed (now with color!) (credit to jakub-g with the original solution: https://gist.github.com/jakub-g/7599177)

git-diff-stat-sort.sh

#!/usr/bin/env bash

# Any additional arguments are passed through to sort command.
# For example, you can order the sort by most changes to least by running with:
#   > git-diff-stat-sort -r
# To pipe the output through the "less" command while preserving coloring, you can use:
#   > git-diff-stat-sort -r | less -R
# Finally, to create a global git command alias, just run the following:
#   >  git config --global alias.diff-stat-sort '!git diff --stat --stat-width "$(tput cols)" --color=always | sort -t "|" -n -k2'
# The above alias will allow you to run the command without having to save/run the below command as a separate script,
# and instead, to just run it as a git subcommand. For example:
#   > git diff-stat-sort
# or even:
#   > git diff-stat-sort -r | less -R
git diff --stat --stat-width "$(tput cols)" --color=always | sort -t '|' -n -k2 "$@"

I think the sort needs a -n, doesn't it?

@fvictorio practically speaking, no. The man page for sort says that keys are white space separated, and the number of lines changed are represented in the git diff —stat output as unsigned integers without leading zeros, so default sort ordering will work. But it certainly wouldn’t hurt to specify numeric sort, so I’ll add it in. Thanks.

so default sort ordering will work

Are you sure about that? Because it doesn't work for me, maybe it's a different git setting?

➜ git diff --stat --stat-width "$(tput cols)" --color=always | sort -k3 "$@"
 b | 10 ++++++++++
 c |  1 +
 a |  2 ++
 3 files changed, 13 insertions(+)

@fvictorio it seems i was evidently talking out of my ass :P out of curiosity, can you share the raw output from git diff --stat --stat-width "$(tput cols)" --color=always so I can see if I can reproduce it on my end? I've never had this issue, and I'm just curious. In the meantime, i'll add in the -n option and you can let me know if that fixes it. Thanks!

huh. Nevermind. found out the issue on my own. I think better fix is to change sort options to sort -k2 -t '|' -n, because there are a few problems with the existing method:

1. sort does not treat consecutive white spaces as a single field separator, annoyingly
2. the placement in the order for the summary line ("3 files changed, 13 insertions(+)...") could technically change depending on your locale specific settings and/or if the format of htat message changes.
3. any spaces in filenames would mess up the sort order because it would change the key being used for comparison.