Christopher 2013-10-07, 19:52
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
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.
> 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
Corey Nolet 2013-10-09, 00:25
Josh Elser 2013-10-09, 00:29
Corey Nolet 2013-10-09, 00:35