git shortlog: how to exclude “(cherry picked from commit ____)” blah?

Question

git shortlog is handy for making a human-readable summary of changes. However, when I cherry-pick changes from the master branch I use the -x flag to git cherry-pick because it records which commit it picked from. This causes some ugliness in the shortlog:

% git shortlog Version-3.5.3..3.5

Dan S (5):
  Fix typo that causes build fail on big-endian archs, thanks Felipe Sateler     (cherry picked from commit 4588258193072cd2fb845f7fb0b4670d6ad5edf2)
  fix build on ARM (where qreal==float); thanks Felipe Sateler     (cherry picked from commit 976d560060185c1e31c9f40660172f0054a4a05c)
  Strip gremlin characters from JITLib wrapForNodeProxy.sc     (cherry picked from commit d0842acae77a90b5eb9811d947ee2dad2282edff)
  choose clipping rather than wraparound for writing integer-format audio     files (libsndfile setting)
  arm build fix: another double->qreal in QcMultiSlider     (cherry picked from commit 548ad319dddf53e4edac1cfa44b3193027eefda2)

Is there an easy way to tell git shortlog that we don't want those cherry-pick lines (which are on new lines in the actual log)?

Of course, I know it's possible to filter them out, for example using git shortlog Version-3.5.3..3.5 | sed 's/[(]cherry picked.*$//g'. But it seems that git should be aware of its own annotations and be able to deal with them. Anything I've missed?

Answer 1

Is there an easy way to tell git shortlog that we don't want those cherry-pick lines (which are on new lines in the actual log)?

Currently, there is no easy way to do it with git shortlog alone.

These cherry-pick lines are added on the second lines of the commit message, so they are considered a part of the commit title by most of the git tools. As Vince suggested, one can try to provide a custom format for shortlog entries (with --format option), however, there seems to be no such pretty-formats or format placeholders that would return only the first line of the subject. (see man git log)

But it seems that git should be aware of its own annotations and be able to deal with them. Anything I've missed?

git shortlog actually seems to be aware only of [PATCH] prefixes (precisely, in terms of regexp: ^\s*\[PATCH[^]]*\]).

To sum up, I think that the best would be to stay with your sed substitution.

Answer 2

You can use the --pretty argument, it's pretty useful if you need to scan a lot of log:

http://gitimmersion.com/lab_10.html

I remember I saw a very extensive resource about it in the past but I can't find it any more. Anyway if this one is not enough, search further.