Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git log – The good parts

zwischenzugs.com

Post reply on HN
Print view View original

61–70 of 86 posts

Re: Git log – The good parts

#61

Post by Stratoscope »

thriftwy wrote: post #23

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

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/

Re: Git log – The good parts

#62

Post by yes_or_gnome »

knux wrote: post #59
dalore wrote: post #21

Earlier quoted context omitted.

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) %Creset'"

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

Re: Git log – The good parts

#63

Post by ibdf »

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.

Re: Git log – The good parts

#64

Post by dahart »

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.

Re: Git log – The good parts

#65

Post by MattyRad »

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.

Re: Git log – The good parts

#66

Post by twic »

TeMPOraL wrote: post #6

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) %Creset' --abbrev-commit" I strongly recommend both. -- [0] - https://magit.vc/ [1] - https://coderwall.com/p/euwpig/a-better-git-log

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

Re: Git log – The good parts

#68

Post by agumonkey »

TeMPOraL wrote: post #6

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) %Creset' --abbrev-commit" I strongly recommend both. -- [0] - https://magit.vc/ [1] - https://coderwall.com/p/euwpig/a-better-git-log

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)

Re: Git log – The good parts

#69

Post by Cyranix »

TeMPOraL wrote: post #6

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) %Creset' --abbrev-commit" I strongly recommend both. -- [0] - https://magit.vc/ [1] - https://coderwall.com/p/euwpig/a-better-git-log

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 " form of limiting the history can be shortened to "-". For example, reviewing the diff of the last two commits can be achieved with "git log -p -2".

Re: Git log – The good parts

#70

Post by pkamb »

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.

Post reply on HN