The only sets of arguments I use to git log regularly:
* `git log branch` because I want to cherrypick or checkout parts of another branch.
* `git log --stat` because what files changed can be a big clue for what I'm looking for.
* `git log -- dir1/ file1/` because I only care about commits to a certain part of the tree.
Other than that, `git log` already provides so much information to /search or even `grep` through that I can't think of any other flags I use regularly, and if you don't use them regularly you forget them.
The real GOAT that people are sleeping on is `git rebase --interactive` where you can go back and edit part of your branch to clean it up before rebasing or merging towards main. The cleaner the commits are, the more useful they become later for other tools like log, merge, rebase, cherry-pick, bisect, etc.
A rebase to clean up your branch is great, and I lean on my team to do this. Unfortunately it's impossible to automate, because it amounts to craftsmanship. I've seen larger teams fall back to squash-merging, which at least discards checkpoint/broken/WIP commits. But it loses the nuance of more complex changes performed in logical stages.
I don't know how my comment was understood to mean that I am unfamiliar with git. My point was that those of us that use the git CLI have no issues seeing the rest of a commit message besides the first line, and in fact this is the default.
https://xkcd.com/2501/
?
Works OK for those of us who don’t know any git flags.