Worth mentioning is "--first-parent" argument to git-log, which is usefull when using git-merge --no-ff to keep clean history with summary commits.

With "--first-parent", git-log only follows the left-hand (first) parent, thus listing the shortened history, by skipping over the right-hand ancestors of merge commits.

I didn't know about --first-parent. Thanks!

Whether or not this makes sense depends on how you manage your commmits. For many projects, I think the changelog would produce too much noise. I would argue that your users care mostly about three things: what bugs were fixed, what new features are available, and any backwards incompatible changes. This can be hard to quickly glean from the commit history.

That said, if your history works with this model, then it's a handy tip :)

I recently started using git. thanks for the tip skiskilo

I'd say shamelessly copied from the much better article from here:

http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-His...

I once needed a ChangeLog file, so I wrote this:

# create ChangeLog file out of git history

alias g.changelog="git --no-pager log --format=\"%ai %aN %n%n%x09* %s%d%n\" | sed \"s/\\ \/*/g\" > ChangeLog"

g.ch<TAB> completes it for me in zsh.