Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Git commit messages


Copy link to this message
-
Re: Git commit messages
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 <[EMAIL PROTECTED]> 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 <[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
>