I also had some thoughts that it would probably be bad to squash commits and retain their messages. If the commits aren't usable independently, then their messages probably aren't useful independently either. If both messages are useful, then it's probably true that both commits were useful as well.
I've really fallen in love with interactive rebase. It turns out that you can use this to re-order commits, and squash them, as well as edit commit messages. For instance, I had a long running feature branch where I was working on two relatively independent features, but my commits were alternating working on one feature, and then the other. I used 'git rebase -i origin/master', and reordered my commits, so the commits for related features were next to each other, and squashed both sets down to just two commits, one per feature. Interactive rebase can help you selectively squash, even if you're already up-to-date/rebase'd onto master already. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Oct 7, 2013 at 3:52 PM, Christopher <[email protected]> wrote: > Looking at some of the latest commits from Corey, as well as some of > the longer messages that seem to wrap when doing "git log --oneline" > > I wanted to make a few suggestions: > > 1) Please include the ticket number at the beginning of the log > message, and in the first line, as it's easier to parse quickly. > > 2) Consider following the git log message format described in Zach > Holman's talk. > http://zachholman.com/talk/more-git-and-github-secrets/ > Slides ~78-98, beginning at 15:20 into the video. > Essentially, this means, leave a short descriptive message in the > first line, skip a line, and write more detailed stuff there, if you > need to. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii
