You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2013/10/07 21:52:17 UTC
Git commit messages
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
Re: Git commit messages
Posted by Corey Nolet <cj...@gmail.com>.
Sorry- link and commenting convention.
On Tue, Oct 8, 2013 at 8:29 PM, Josh Elser <jo...@gmail.com> wrote:
> 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 accumulo.apache.org?
>>
>>
>> On Mon, Oct 7, 2013 at 4:02 PM, Christopher <ct...@apache.org> 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
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Mon, Oct 7, 2013 at 3:52 PM, Christopher <ct...@apache.org> 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/<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
>>>>
>>>
>
Re: Git commit messages
Posted by Josh Elser <jo...@gmail.com>.
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 accumulo.apache.org?
>
>
> On Mon, Oct 7, 2013 at 4:02 PM, Christopher <ct...@apache.org> 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
>> http://gravatar.com/ctubbsii
>>
>>
>> On Mon, Oct 7, 2013 at 3:52 PM, Christopher <ct...@apache.org> 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
Re: Git commit messages
Posted by Corey Nolet <cj...@gmail.com>.
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 accumulo.apache.org?
On Mon, Oct 7, 2013 at 4:02 PM, Christopher <ct...@apache.org> 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
> http://gravatar.com/ctubbsii
>
>
> On Mon, Oct 7, 2013 at 3:52 PM, Christopher <ct...@apache.org> 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
>
Re: Git commit messages
Posted by Christopher <ct...@apache.org>.
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 <ct...@apache.org> 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