accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Git commit messages
Date Wed, 09 Oct 2013 00:29:50 GMT
I'm all for it. That presentation is one of the best I've ever read 
about Git.

On 10/08/2013 08:25 PM, Corey Nolet wrote:
> Chris,
> Thanks for the link! I'll be sure to follow that convention from now on. I
> should have been paying closer attention to everyone else's commit messages
> because it looks like I'm the only one who's been putting the ticket number
> after the message. Would anyone be against placing the link on the Git WiP
> page on
> On Mon, Oct 7, 2013 at 4:02 PM, Christopher <> wrote:
>> 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 <> 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

View raw message