You should probably avoid `--color`, as it turns on color unconditionally, even if output is going to a file. In older versions of Git the %C color placeholders were unconditional anyway. In modern Git, they respect the normal auto-coloring settings.
You can also drop `--abbrev-commit`, since `%h` abbreviates by default (use `%H` if you want the full hash).
This is likely to be said, "`--color=auto` is the default setting, so it's not needed." However, it's good to include it here because some users may have changed their default configuration to disable colors. This way `git log` works as their standard workflow and `git lg` for when they need a bit of color.
lg is the normal log, glg is with the graph, slg lists my stashes in the same format (i find the date really helpful), and blg does the same for branches.
blg can't reuse a pretty definition because it uses a completely different formatting language. The fact that Git contains two different but largely equivalent formatting languages is kind of emblematic of its whole design, really.
Like heipei, i put the fixed-width bits on the left so that they line up. I try to use consistent and distinctive colours for everything; mostly that's obvious, but yellow draws an equivalent between branch names for the normal and branch logs, and stash refs for the stashes. Including committer name for stashes is perhaps foolish consistency, although it would be useful if you do pair programming and use something like git-duet.
This allows me to skim through my own recent changes.
"--no-merges" is included in just about every log invocation I run; in a continuous integration workflow, I generally don't find merge commit info to be all that informative.
As an additional tip, the "-n <count>" form of limiting the history can be shortened to "-<count>". For example, reviewing the diff of the last two commits can be achieved with "git log -p -2".
gitk 7-8 years ago, Github desktop app few years later. I used version control features in Eclipse and IntelliJ for SVN, but I believe the same interface maps to Git as well.
None of them even compare with Magit. They offer a small subset of Git features - unlike Magit, which gives you almost all of them, + some higher level abstractions (like "merge into"), and you're always one ! ! press away from entering a manual command. Also, the other interfaces I've used were mostly mouse based, whereas Magit just flows. Feels order of magnitude more efficient than anything else.
Also useful: any time you find yourself wondering what did Magit just do, press $ to display raw output from git commands (lists the commands issued and their return codes, TAB expands them to full output).
Magit had a Kickstarter recently (yes, an Emacs mode on Kickstarter; I was shocked too), to raise funds for continued development. I dropped some cash there; after all, it helps me quite a lot to earn my paycheck.
is it because Kickstarter is contradictory to FSF mindset ?
I couldn't pay on KS so I asked him his paypal handle, but it was the KS campaign that motivated me. As you said, it's a great asset to the day of developpers (or any document maintainer under git)
--
[0] - https://magit.vc/
[1] - https://coderwall.com/p/euwpig/a-better-git-log