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)
I would recommend tig for anyone looking for a cli git repo browser: https://jonas.github.io/tig/ Then there's no need to mess with git log and all its options.
Second that, I love tig as a history browser. However for Git tree manipulation I find it a little disappointing. A lot can be customised with shortcuts, but it feels a little cumbersome and you need to restart for some changes to be visible.
• Since the --decorate option is now enabled by default (at least since Git 2.13), I don't have the --decorate option in my aliases. You may have to add them if you are using an older version of Git.
• Often while looking at the commit log, I need to know the commit date and the committer name which --oneline option does not show by default, so instead of using the --oneline option, I am formatting the one-liner logs myself with the `--pretty=format:` option to see these details.
The --simplify-by-decoration option is a nice one, something I can add to my list of aliases.
I have these aliases and a few other useful aliases documented in a bonus section named "Nifty Commands" in a fork and pull request workflow document I shared on Hacker News about a month ago. Here is the URL: https://github.com/susam/gitpr.
A quick mnemonic I read on StackOverflow[1] some time ago:
When using git log, do it like "a dog"
git log --all --decorate --oneline --graph
I must say I had forgotten about the `--all` part, but the article mentions that it should be on by default if running interactively in the terminal, at least with recent versions of git.
An unappreciated flag of git is `--no-pager`. It allows, as said in the name, to execute a git command without using a pager.
Using this flag, my git log aliases to: `git --no-pager log --pretty=oneline -n30 --abbrev-commit`. It just shows the 30 last commits directly in my command line
Of all the git log variants that I have come across I find this one the most clean, easy to parse, and nicely formatted. I think I found it on HN somewhere. Maybe someone finds it as useful as I did
You don't need fancy GUI's, nor do you need to remember long flag names, when there is tig - text mode interface to git. You only need to remember it's "git" backwards:
I like this the idea of showing the most common use cases for a git command (or at the very least, a valuable use case), separating the sections by building out the flags and options.
The git man pages, while thorough, don't provide anything this concise. I could easily add these commands as aliases, which I appreciate.
I wish git log had a native columnized one-line output, it's hard to read with variable length fields. You can (and I did) use the --pretty option to format the log output, and columnize it. But that's involved (my git 'columnized log' script is ~100 lines long) and hard to share.
I like GitExtensions. I cringe when i see people manually entering hashes when they want to do stuff such as simple diffs. It's busy work. Hammering away on the keyboard but actually accomplishing so little.
I can't imagine developing or sorting out repo issues without a full tree-view of the last hundred commits showing branches, merges, SHAs, tags, authors, commit messages, etc.
But it's just another tab in my GUI app (sourcetree), not a complicated set of flags that needs a blog post to explain.
The use of git as a command-line-only tool is completely strange and alien to me. It works so well as a full-fledged graphical app.
I work for a small game studio with a couple of programmers and artists, and we use git for source control (which works for us, our binary assets aren't big enough to make git too much trouble). Most of our team is non-programmers, and I've become the "go-to git guy" at my company. All the others use Sourcetree, so I have lots of experience with it, and I can tell you: I would never pick Sourcetree over command line git.
Sourcetree is an okay piece of software, but command-line git is so much faster to use. Even doing simple things like adding, committing, pulling and pushing takes half the time on the command line for me compared to Sourcetree. For this particular logging issue, you don't actually type up all those flags every time, you make an alias and it takes no time at all. If you're trying to do anything marginally complicated (say, bisecting or using the reflog), Sourcetree is all but useless.
Command line git is harder to learn and harder to use in the beginning (and virtually impossible to use unless you're comfortable with the terminal), but if you're using the terminal a significant amount anyway, it's just a better solution.
I will say: the last couple of weeks, I've been trying to get into the habit of using magit, and it's the only git client I've used that can compete with the command line. Sourcetree certainly can't, not for me.
My experience is coworker developers struggling-at-best to use git from the command line in the simple case, and having almost no visibility into the tree/history of the repository for use in debugging. Or being unaware of useful git features such as line-by-line selective staging (that I consider absolutely essential for dev teams).
I don't particularly like SourceTree, and it is slow and annoying in certain ways. But I'm extremely productive with it as a poweruser, and it's much better for beginners as well.
Sometimes I like to generate a summary for release note purposes. The shortlog command (which is what git merge uses) is good for that. https://git-scm.com/docs/git-shortlog
My personal favorite is `git log -p --` because it actually shows you the content that changed.
Or, to show you what changed on each given single line, use `git log -p --color-words --`. Far more useful for long lines, IMO.
I'm also a fan of `git log -LN,N:filename`, where N is a line number. It gives you a log of that particular line number. It's like `git blame` but better.
git reflog pales in comparison to SmartGit's log view.
Just click the Recyclable Commits checkbox, and all the commits from the reflog are shown in the normal SmartGit log, integrated into the view just like every other commit, with all of SmartGit's usual tools available.
Want to see which files changed in a particular commit? Click the commit.
Want to see the diff for one of those files? Click the file.
It's all right there. No copying commit hashes or having to use any other commands to see what changed.
Stashes are treated the same way. Click the Stashes checkbox and they are also displayed as part of the normal log with all tools available.
I really like the way SmartGit integrates these separate Git features into a single unified log view.
Thanks for sharing. I've been forcing myself to be independent from a git GUI, and just learn the commands. I didn't even know that was a --graph option to git log.
Nevermind, I made a mistake and tested it on a repo where ---all would have little noticeable effect. It is indeed disabled by default.
That said, custom source edits are entirely possible. Canonical does keep their own repositories after all [1].
Sourcetree is awful and slow. There is git gui by default, which is not perfect but IMO better that cli. I actually use Git Extensions for years now and could not find anything better.
I used to love sourcetree, but after the redesign the whole thing became so slow I just went back to using CLI tools. Maybe it's for the better, as I can be way more flexible this way.
First you load mountains of code and assets. Then you have to remember which collapsed menu is hiding your target, then you go there and look around and hit it, then wait another 15s to load the next pile of crap. Can't they at least use the real estate if you have it, instead of always hiding?
I'm tired of it. None of their thrash is benefiting me.
--
[0] - https://magit.vc/
[1] - https://coderwall.com/p/euwpig/a-better-git-log