Hacker News new | past | comments | ask | show | jobs | submit login
Git log – The good parts (zwischenzugs.com)
338 points by okket on Mar 26, 2018 | hide | past | web | favorite | 83 comments



For those increasingly rare times I'm not using Magit[0], I have a "git lg" alias I found once through HN[1]:

  git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
I strongly recommend both.

--

[0] - https://magit.vc/

[1] - https://coderwall.com/p/euwpig/a-better-git-log


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).


For the lazy:

  git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'"


We must have started from the same source. I've since added displaying message bodies by default, but similar otherwise:

lg = log --graph --date=relative --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset%n%w(0,4,4)%-b%n%n%-N'


You can still add color when not piping or writing to a file with `--color=auto`.

      git config --global alias.lg "log --color=auto --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'"


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.


I use the following since it keeps the abbreviated hash and date of the commit in their own "columns", making it easy to skim:

  git log --date=short --pretty=format:"%C(124)%ad %C(24)%h %C(34)%an %C(252)%s%C(178)%d"


Since we're sharing:

    [pretty]
    	lg = %C(red)%h%C(reset) %C(green)%ci%C(reset) %s %C(bold blue)-- %an%C(reset)%C(yellow)%d%C(reset)
    	lge = %C(red)%h%C(reset) %C(green)%ci%C(reset) %s %C(bold blue)-- %an <%ae>%C(reset)%C(yellow)%d%C(reset)
    	reflg = %C(red)%h%C(reset) %C(green)%ci%C(reset) %s %C(bold blue)-- %an%C(reset) %C(yellow)(%gd)%C(reset)
    [alias]
    	lg = log --pretty=lg
    	glg = log --graph --pretty=lg
    	slg = stash list --pretty=reflg
    	blg = branch --format '%(color:red)%(objectname:short)%(color:reset) %(color:green)%(committerdate:iso)%(color:reset) %(subject) %(color:bold blue)-- %(authorname)%(color:reset) %(color:yellow)(%(refname:short))%(color:reset)'
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.


> The fact that Git contains two different but largely equivalent formatting languages is kind of emblematic of its whole design, really.

tip of the iceberg.


I haven't seen anyone share an author-filtering use case yet, so here's a lightly-edited version of my "git mine" alias:

  log --no-merges --date=short --author="cyranix" --stat
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".


I use a light variant from it :

  git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date-order"


The difference is an added --date-order:

"Show no parents before all of its children are shown, but otherwise show commits in the commit timestamp order."


lol, I named my alias `git lol` because it is logs in one line.


lol, I named mine 'git l' because I type it far too often.


I use two-letter bash aliases for all my most commonly used git commands.

    git status
    git diff
    git diff --cached
    git add -A
    git commit -m Hello
    git push
Is instead just

    st
    dp
    di
    aa
    cm Hello
    pu
Additionally I also have

    le
For

    git shortlog -s -e
which I don’t use very often but often enough that having an alias for it still makes sense


I edited my inputrc to do a prefix search. So I just ‘git x’ where x is some letter, pressing up usually finds me what I want.

It still surprises me we don’t have good bash autocomplete.

Not sure how hard it is to create a shell but i’d do it in a heartbeat.


i think 'xonsh' aims to do that


Mine is only `gl`, but I edited my .zshrc for that.


I named my custom logging command 'git ls', which is an idiotic name (that should list files or something), but I'm stuck with it now :)


mine is assigned to the bash alias "gl"


Many of us at work have the following alias in our .gitconfig file:

lola = log --graph --decorate --pretty=oneline --abbrev-commit --all

This is similar to others posted here.


Have you tried other git UIs (IDE or not) ?

I wonder if there's one that is as good as magit (my opinion is no, but that's why I ask)


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.


> you're always one ! ! press away from entering a manual command

Huh, I didn't know this. I'll probably live in Magit from now on.


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).


I don't do it that often but I felt compelled to tip magit maintainer because it's just a beautiful and important piece of my emacs life.


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 couldn't bare those relative times.

My prefered tool is `tig --all` which gives me a nice view of the repo with its branches.


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.


In case anyone finds these useful, here are some git log aliases I use everyday.

    FORMAT="%C(auto)%h %C(magenta)%ad %C(cyan)%an%C(auto)%d %s"
    PRETTY="--pretty=format:'$FORMAT' --date=short"
    git config --global alias.lga "log --graph --all $PRETTY"
    git config --global alias.lg "log --graph $PRETTY"
    git config --global alias.la "log --all $PRETTY"
    git config --global alias.ll "log $PRETTY"
    git config --global alias.lf "log --pretty=fuller --stat"
There are two interesting things to note here:

• 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.


Git has a built-in way of achieving what you've done with the $FORMAT and $PRETTY variables; look at @twic's comment on this story.


Commands in the article:

    git clone https://github.com/ianmiell/cookbook-openshift3-frozen
    cd cookbook-openshift3-frozen
    git log
    git log --oneline
    git log --oneline --decorate
    git log --oneline --decorate --all
    git log --oneline --decorate --all --graph
    git log --oneline --decorate --all --graph --simplify-by-decoration
    git log --oneline --decorate --all --graph --stat
    git log -G 'chef-client' --graph --oneline --stat
    git log -G 'chef-client' --graph --oneline --stat --pickaxe-all


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.

[1]It might have been https://stackoverflow.com/questions/1057564/pretty-git-branc... but I am not 100% sure.


So the obvious alias would be

    git config --global alias.logadog "log --all --decorate --online --graph"


I don't believe the article's claim about --all being on by default is true.


It's not, it was a typo I've corrected.


This reminds me a bit of my `hg wip` command:

http://jordi.inversethought.com/blog/customising-mercurial-l...

It eventually got mainlined into Mercurial as the `hg show` command:

https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_4.3_.2...


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


Another useful option is '--first-parent'

One use case is : "when did branchA fork from master ?"

git log --graph --oneline --... --first-parent branchA master


That's a good one... I'll probably add that tonight after work.


This is my preferred git log command:

  git config --global alias.lg "log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all"
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:

https://jonas.github.io/tig/

Screenshot of main view:

https://www.flickr.com/photos/jonasfonseca/3316428644/in/alb...

Available in most repos (ubuntu, homebrew I think, etc). Never understood why it's not more widely known than it is.


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 Tortoisegit. No commands to memorize and the entire product can be worked via the keyboard.

https://i.stack.imgur.com/Xc9vb.png


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.


Thanks! I would really like something that integrates with Finder on the Mac and I see that it is cross platform, so I will have to try that out.


I just spent 15 minutes entering different Git log commands. Good times.


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.


"git log" was yesterday, "git lol" is the new hip thing. Give it a shot: https://github.com/erikbgithub/dot-files/blob/master/.gitcon...


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


I can't use git without "git gl":

    [alias]
    gl = log --pretty=format:\"%x1b[33m%h%x1b[36m%d %Cgreen%ae %Cred%ad%Creset%n%s%n\" --graph --date=local
Try this in your .gitconfig. I highly recommend it.


I don't see it mentioned anywhere, but

    git log -N (where N is 1, 2, 3, 4...)
will show the last N commits only. I find myself doing `git log -1` pretty often to see what was the last commit, so I imagine I'm not the only one.


'git show' does that too.


The best part of git log is git reflog. It's like suddently having eyes to see.


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.

https://www.syntevo.com/smartgit/


I discovered --simplify-by-decoration thanks to the article. Thank you :)


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.


Quote from article:

"Remember that your version might do --all by default when output goes to the terminal instead of a file"

Which version of Git does --all by default?


I think they meant to say "might do --decorate by default" (which Git does since v2.13.0).


Indeed, have updated - the all and decorate sections got jumbled up in an edit earlier.


The ones distributed in Ubuntu and MinGW do. Probably many others as well.

EDIT: Or not. It's off by default actually.


Which version of Ubuntu? The last time I checked, --all was not enabled by default in Ubuntu? Can someone confirm if this is indeed true?

If this is indeed true, how do they achieve this? Do they modify git source code to achieve this?


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].

[1] - https://launchpad.net/git


You can't override existing Git commands with aliases.


> 15-team project that doesn’t rebase

Holy un-scalable code base Batman.


Or use sourcetree


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.


Which Git GUI present by default do you find better than CLI? gitk? Or do you have something else in mind?


Not present by default, but I like QGit for history browsing: http://libre.tibirna.org/projects/qgit/wiki/QGit


This one where you just type in 'git gui' and it pops up. https://git-scm.com/docs/git-gui


`git gui` is not a commit tree browser though. It's used for making commits.


Menu -> Repository -> Visualize

You can visualize current branch or all branches. It also has search, diffs and quite some options.


You can't run sourcetree output through grep, sed and xargs though.


Curious, why would you run log through those? It already has flags to support getting birth the messages and the diffs.

Granted, familiarity and reflex are decent reasons.


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.


Atlassian seems to be really good at redesigns that make things slow. Jira anybody?


Doubly slow if you count hamburger menus.

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.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: