A better git log(coderwall.com)
coderwall.com
A better git log
http://coderwall.com/p/euwpig?i=3&p=1&t=git
72 comments
I got them from here: http://pyrtsa.posterous.com/aligning-your-git-logs (which also has the list-not-graph versions).
[Which is what I was going to comment, but you beat me to it.]
[Which is what I was going to comment, but you beat me to it.]
If you like this you should already be subscribed to Destroy All Software: outstanding value for the dollar. I actually prefer Gary's "git r" and "git l" to this.
If you really want to skip on the awesomeness that is DAS, he has his dotfiles up on github that are chock full of great tidbits: https://github.com/garybernhardt/dotfiles
If you really want to skip on the awesomeness that is DAS, he has his dotfiles up on github that are chock full of great tidbits: https://github.com/garybernhardt/dotfiles
Many people don't realize there's a graphical interface built into git: gitk
tig is cool too. It's an ncurses based interface for exploring git history. apt-get install tig; and then run tig; in any directory that's a git repo
+1 for tig. tig blame is also excellent, you can easily drill down to see who changed a line. Plus tig is a great replacement for git log since it launches in around 0.25 seconds compared to 1+ seconds for gitk and other graphical viewers.
+1 for tig, you can also brew install tig
magit does the right thing for "emacs users".
Came here to suggest tig; one nice feature about it is that if you're annotating a file in the "blob" view (IIRC), the annotation information streams in as tig walks the commit tree backwards. This can be nice in a repository with thousands of commits.
I find myself using these aliases regularly:
df = diff --color --color-words --abbrev
st = status -s
l = log --graph --pretty=oneline --abbrev-commig --decorate
There are a lot more at this stackoverflow thread: http://superuser.com/questions/169695/what-are-your-favorite...From my .gitconfig:
# --- LOGS ---
ll = "log --pretty=oneline --abbrev-commit"
lg = log --pretty=oneline --abbrev-commit --graph --decorate --date=relative
lgt = log --graph --pretty=format:'%Cred%h%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative
lgtt = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative
I almost never user "git lgt" or "git lgtt." Instead I mostly use "git ll", and sometimes "git lg", though if you're doing a lot of merging around, the graph can get a bit convoluted.Is there a way to make the filenames in a 'git diff' stand out/coloured? I always have trouble figuring out where one file's diff ends and the next one begins.
thanks! A minor improvement would be to put tree-ish at the end;
log --graph --pretty=format:'%Cred%h%Creset - %s %Cgreen(%cr) %C(bold blue)<%an>%Creset %C(yellow)%d%Creset' --abbrev-commit --This page looks rather surprising with Javascript disabled. It seems to be leaking all of the "behind the scenes" details which ultimately become the post, like this:
Just type in: git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
That seems ... suboptimal.I think that's just what you're supposed to type in.
(I see that too, with JS enabled, and if you view source you can see that that was intentional based on the > and <.)
(I see that too, with JS enabled, and if you view source you can see that that was intentional based on the > and <.)
The final example with "-p" doesn't seem to work, because of the "--". That "--" shouldn't be needed most of the time, and can be manually added if you want to specify file names that clash with branch names, etc. Otherwise, this is really neat.
Instead of hardcoding those colors, I'd suggest:
git config --global color.ui "auto"
Now, this already gives you most of articles info: git log --decorate --graph --oneline"Look, here's a pretty way to configure git! This can also be done in these 17 other ways, wheeeee! It's 2012 and the top article is how to configure colours in 'git log'"
Seriously, boffins. Stop posting this stuff already. Better techniques are nice, but good only if they're revolutionary (like that Light Table editor). We need more new, ground-breaking stuff and less arrangements of Linus's Lego bricks.
Seriously, boffins. Stop posting this stuff already. Better techniques are nice, but good only if they're revolutionary (like that Light Table editor). We need more new, ground-breaking stuff and less arrangements of Linus's Lego bricks.
agree 100%. the '5 minute' newscycle of tech blogs leads to needless repetition of dumb stuff.
Any news cycle tends to repetition of stuff.
There's the annual calendar of "news" stories pertaining to major holidays, sports events, and political cycles.
If you've lived a few years (or decades) in any particular area, you'll find a recycled set of "places to go, things to do, sights to see" articles.
If you've lived through a few economic cycles, there's a very predictable trend through boom, cusp, bust, downturn, recovery cycles (NB: still in the downturn).
News is cyclic. Not everyone knows everything. Reiterating the basics every so often is necessary.
The challenge isn't not doing it, but getting the balance right.
There's the annual calendar of "news" stories pertaining to major holidays, sports events, and political cycles.
If you've lived a few years (or decades) in any particular area, you'll find a recycled set of "places to go, things to do, sights to see" articles.
If you've lived through a few economic cycles, there's a very predictable trend through boom, cusp, bust, downturn, recovery cycles (NB: still in the downturn).
News is cyclic. Not everyone knows everything. Reiterating the basics every so often is necessary.
The challenge isn't not doing it, but getting the balance right.
"good only if revolutionary" sure would make for a sparse & boring HN front page...
I appreciate this tip (and upvoted it) as I hadn't thought of the idea before. Revolutionary? No. Helpful? Absolutely.
I appreciate this tip (and upvoted it) as I hadn't thought of the idea before. Revolutionary? No. Helpful? Absolutely.
> "good only if revolutionary" sure would make for a sparse & boring HN front page...
Sparse yes, boring I don't think so.
Sparse yes, boring I don't think so.
Nice.
Why is the last -- needed? This restricts giving other wise optional flags to git log.. Can list last n commits for example.
Why is the last -- needed? This restricts giving other wise optional flags to git log.. Can list last n commits for example.
Your screenshots are JPEGs; they would look much better as PNGs.
Also I should be able to click on the image, instead of the link below the image, to see it fullsize.
How do you keep track of such changes across machines? In a dotfiles git repository, and making a symbolic link to your git configuration stored there?
That's exactly how I do it. https://github.com/felixhummel/configs#readme
I just use a ~/.git
This is not really new, for those looking into a smart, user friendly git client, try G2 - http://orefalo.github.com/g2/
Strange but true, the widespread `git lola` has not been mentioned yet.
[alias]
lol = log --graph --decorate --pretty=oneline --abbrev-commit
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
http://blog.kfish.org/2010/04/git-lola.htmlEven simpler (git 1.7.7, YMMV)
[alias]
lol = log --graph --decorate --oneline
lola = log --graph --decorate --oneline --allWhat's the options to make git show the files that changed in each diff?
An open-source git client for OS X which I think is criminally underused is Laullón's fork of GitX at http://gitx.laullon.com/ ... it's a beautiful and full-featured interface that feels right at home in the GUI. Can't beat the price, and it's light-years ahead of GitHub for Mac.
I use it and it's quite good. Can't fully replace the shell though. One thing that I don't get is why it takes a few seconds (10 ish) to make a local branch.
SourceTree is what I use, but even that is falling apart at the size of our Git Repo. GitX just falls over for me.
I use SourceTree, but it is slow.
wow, this is amazing. git log has options? and you can use them? who knew.
I use 'git h', which is very similar. It was gifted to me when I moved to SF.
(in ~/.gitconfig under the [alias] section...)
h = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
https://img.skitch.com/20120619-c9xq67ysdbmrasmfgur6raba1d.p...
I'd love to see how stuff like this spreads. I just use git h because the person that gave it to me used that.
(in ~/.gitconfig under the [alias] section...)
h = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
https://img.skitch.com/20120619-c9xq67ysdbmrasmfgur6raba1d.p...
I'd love to see how stuff like this spreads. I just use git h because the person that gave it to me used that.
A bit off topic: I like the font you're using on your console screenshot, but I'm having trouble narrowing down what it is. Do you mind telling us?
Looks like Inconsolata [1] to me. The slashes are set slightly higher than the pipe, the asterisk is vertically center-aligned (as opposed to super-positioned as with Consolas, Monaco, Vera Sans Mono and others), a distinctive upward curve on its lowercase 'y', and it has a looptail lowercase 'g'.
[1] - http://levien.com/type/myfonts/inconsolata.html
[1] - http://levien.com/type/myfonts/inconsolata.html
Does anyone have a setup where the git log (perhaps with grep) is synced with their public changelog file?
My only complaint is, I write long commit messages, since the commit messages are shown in single line, it overflows the viewing area. so, if there are linebreaks for longer git messages, it would be awesome.
Git best practices say the first line in your commit message should be no more than 50 characters. Subsequent lines should be wrapped at 80 characters. See http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa...
I've been using multiple lines in my log messages, but didn't know about second blank line.
I tried as per pilgrim689's comment, Now everything is fine with --oneline argument.
Thanks.
I tried as per pilgrim689's comment, Now everything is fine with --oneline argument.
Thanks.
Long commit messages are good, but if you want them to display nicely in short logs, enter them the way git and linux kernel commit messages do:
<short 1-liner explaining change>
<blank line>
<paragraph with commit details>
then `git log --oneline` displays the 1-liners perfectly.
<short 1-liner explaining change>
<blank line>
<paragraph with commit details>
then `git log --oneline` displays the 1-liners perfectly.
Is there a way to limit this to the most recent N (either hard-coded or as an input) entries? It's a bit slow to load when it has to load all of the history ever, and I usually only care about at most the last couple dozen commits.
The built in automatic paging in git already makes sure it does not have to load all history. And --graph is what makes it slow. Adding a limit with git lg -10 seems to take about the same time as with no limit at all.
Ah, thanks for the correction.
Knowing that, this doesn't really matter, but "git lg -10" produces no output at all for me.
Knowing that, this doesn't really matter, but "git lg -10" produces no output at all for me.
I also find it very helpful to spiff up my prompt when changing into a git repo:
http://railstips.org/blog/archives/2009/02/02/bedazzle-your-...
http://railstips.org/blog/archives/2009/02/02/bedazzle-your-...
Tried it, for some reason isn't working on my system.
Then found this: http://volnitsky.com/project/git-prompt/ and I'm loving it!
Then found this: http://volnitsky.com/project/git-prompt/ and I'm loving it!
There's a __git_ps1 function that's included with the git bash completion script (edit: it works with zsh, too -- the __git_ps1 function and the completion).
Hm, I think something's missing from the post... Oh, yes, proper attribution.
I saw this months ago in a 2010 blog post: http://www.jukie.net/bart/blog/pimping-out-git-log
It's the exact same alias, sans "--date=relative".
The guy from jukie.net also shares his entire .gitconfig, I built mine from it and highly recommend at least taking a peek: http://www.jukie.net/~bart/conf/gitconfig
I saw this months ago in a 2010 blog post: http://www.jukie.net/bart/blog/pimping-out-git-log
It's the exact same alias, sans "--date=relative".
The guy from jukie.net also shares his entire .gitconfig, I built mine from it and highly recommend at least taking a peek: http://www.jukie.net/~bart/conf/gitconfig
lg50 = "!git log --graph --abbrev-commit --date=relative --pretty=format:'%x00%h%x00%s%x00%cd%x00%an%x00%d' | gawk -F '\\0' '{ printf \"%s\\033[31m%s\\033[0m %-50s \\033[32m%14s\\033[0m \\033[30;1m%s\\033[0m\\033[33m%s\\n\", $1, $2, gensub(/(.{49}).{2,}/, \"\\\\1…\",\"g\",$3), $4, $5, $6 }' | less -R"
lg80 = "!git log --graph --abbrev-commit --date=relative --pretty=format:'%x00%h%x00%s%x00%cd%x00%an%x00%d' | gawk -F '\\0' '{ printf \"%s\\033[31m%s\\033[0m %-80s \\033[32m%14s\\033[0m \\033[30;1m%s\\033[0m\\033[33m%s\\n\", $1, $2, gensub(/(.{79}).{2,}/, \"\\\\1…\",\"g\",$3), $4, $5, $6 }' | less -R"
Note: i've been using them for some time, i don't even remember who was the original source...
On an unrelated note, does someone remember how to add code sections? :)