You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Chris Hillery <ch...@hillery.land> on 2015/09/17 22:14:11 UTC
Commit message proposal
At Couchbase, we have a commit message standard which has proven useful.
All git commit messages must start with a short one-line summary of no more
than 60 characters or so. Then a blank line, followed by additional
details, specifics, etc. all on lines of no more than 72 characters. If
it's a simple enough change that the one-line summary is all you need,
that's fine too.
Additionally, if the commit is for a specific ticket, that ticket number
must be at the beginning of the summary line, followed by a colon. FYI our
tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
------
ASTERIXDB-1097: Fix threading in printers
Replace static data member with a safe thread-local instance to
avoid data corruption.
------
This really helps in tracking git history - there are several commands
which will only display the first line of a commit message, for instance,
so having it be self-contained makes it much easier to read. You may also
have noticed that Gerrit uses that first line for the subjects of emails it
sends out. Also, by including the ticket name, we can easily configure
Gerrit to provide a hyperlink to the ticket to make things easier to review.
Here's a blog post which goes into excruciating detail about commit
messages:
http://chris.beams.io/posts/git-commit/
Ceej
aka Chris Hillery
Re: Commit message proposal
Posted by Till Westmann <ti...@apache.org>.
+1 on the commit messages (but I think that we don't necessarily need to
have a tool check it).
Wrt the squashed commits, the reason for me to prefer them is, that one
gets a nice and understandable history on the master branch. With
several commits - even if they are linked in some way - it gets much
harder to understand what the complete change is that was done to fix a
problem. Especially if there are several rounds of reviews and fixes, it
seems not very useful (from a human perspective) to keep all the
intermediate commits in the history.
Now I also never had the problem of several dependent feature branches,
so I might not appreciate the problem enough.
My 2c,
Till
On 17 Sep 2015, at 22:08, Chen Li wrote:
> I support the idea of enforcing certain rules on commit messages.
>
> Regarding squashing commits, it has pros and cons. I know in other
> projects people keep all individual commits. I want to hear the
> reason of our current practice of squashing commits.
>
> Chen
>
> On Thu, Sep 17, 2015 at 8:59 PM, Jianfeng Jia <ji...@gmail.com>
> wrote:
>> Second the proposal first. It is a good way to track the git with
>> jira.
>>
>> Another separate but related thought, since we enforce the commit
>> message format, e.g. starting with jira ticket,
>> can we just rebase but do NOT squash the commit when merging into the
>> master?
>> Then the commit is more atomic. It’s easy to pick/merge across the
>> different branches.
>>
>> In my case, right now I’m facing the merging problem which is not
>> only caused by the package name changes
>> but also that my personal feature branches dependent on each other.
>>
>> Let’s say, I’m finishing working on A, and also I have ongoing
>> branches B which is based on some parts of A.
>> After review of A, all A’s commits are squashed to master. At that
>> time I have to merge master to B,
>> but git can’t find the shared part anymore. In contrast, it showed
>> the false “conflicts” everywhere.
>>
>> If we keep the initial atomic commits, git will know the shared
>> parts. And also, since we link the commits
>> by ticket name, we don’t need to squash them together in order to
>> know which commit is doing what.
>> Does it make sense?
>>
>>
>>> On Sep 17, 2015, at 8:15 PM, Chris Hillery <ch...@hillery.land>
>>> wrote:
>>>
>>> I implemented a process at Couchbase that can be used to validate
>>> whatever
>>> we want about a proposed commit, including the form of the message.
>>> I could
>>> do the same here, with some basic rules in place like "first line no
>>> longer
>>> than 70 characters, blank line before any additional lines", etc. I
>>> could
>>> also validate at least that if there IS a ticket associated with the
>>> message, that it's in the right place and references an actual valid
>>> ticket.
>>>
>>> Ceej
>>> aka Chris Hillery
>>>
>>> On Thu, Sep 17, 2015 at 8:12 PM, Ian Maxon <im...@uci.edu> wrote:
>>>
>>>> Sounds like a great idea to me. I was talking with Jianfeng in the
>>>> hall about this today, and the idea came up that there might be a
>>>> way
>>>> to enforce this via a git hook or similar at Gerrit's end.
>>>>
>>>> Thoughts? I am not sure myself if this should be a strict rule
>>>> (i.e.
>>>> you must file tickets to commit) or if it should be on the burden
>>>> of
>>>> the reviewer to verify that.
>>>>
>>>> - Ian
>>>>
>>>> On Thu, Sep 17, 2015 at 1:39 PM, Taewoo Kim <wa...@gmail.com>
>>>> wrote:
>>>>> +1
>>>>>
>>>>> Best,
>>>>> Taewoo
>>>>>
>>>>> On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <ec...@ucr.edu>
>>>>> wrote:
>>>>>
>>>>>> I like the proposal. This will be helpful when got and Jira are
>>>>>> linked.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>> On Sep 17, 2015, at 1:14 PM, Chris Hillery
>>>>>>> <ch...@hillery.land>
>>>>>> wrote:
>>>>>>>
>>>>>>> At Couchbase, we have a commit message standard which has proven
>>>> useful.
>>>>>>> All git commit messages must start with a short one-line summary
>>>>>>> of no
>>>>>> more
>>>>>>> than 60 characters or so. Then a blank line, followed by
>>>>>>> additional
>>>>>>> details, specifics, etc. all on lines of no more than 72
>>>>>>> characters.
>>>> If
>>>>>>> it's a simple enough change that the one-line summary is all you
>>>>>>> need,
>>>>>>> that's fine too.
>>>>>>>
>>>>>>> Additionally, if the commit is for a specific ticket, that
>>>>>>> ticket
>>>> number
>>>>>>> must be at the beginning of the summary line, followed by a
>>>>>>> colon. FYI
>>>>>> our
>>>>>>> tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
>>>>>>>
>>>>>>> ------
>>>>>>> ASTERIXDB-1097: Fix threading in printers
>>>>>>>
>>>>>>> Replace static data member with a safe thread-local instance to
>>>>>>> avoid data corruption.
>>>>>>> ------
>>>>>>>
>>>>>>> This really helps in tracking git history - there are several
>>>>>>> commands
>>>>>>> which will only display the first line of a commit message, for
>>>> instance,
>>>>>>> so having it be self-contained makes it much easier to read. You
>>>>>>> may
>>>> also
>>>>>>> have noticed that Gerrit uses that first line for the subjects
>>>>>>> of
>>>> emails
>>>>>> it
>>>>>>> sends out. Also, by including the ticket name, we can easily
>>>>>>> configure
>>>>>>> Gerrit to provide a hyperlink to the ticket to make things
>>>>>>> easier to
>>>>>> review.
>>>>>>>
>>>>>>> Here's a blog post which goes into excruciating detail about
>>>>>>> commit
>>>>>>> messages:
>>>>>>>
>>>>>>> http://chris.beams.io/posts/git-commit/
>>>>>>>
>>>>>>> Ceej
>>>>>>> aka Chris Hillery
>>>>>>
>>>>
>>
>>
>>
>> Best,
>>
>> Jianfeng Jia
>> PhD Candidate of Computer Science
>> University of California, Irvine
>>
Re: Commit message proposal
Posted by Chen Li <ch...@gmail.com>.
I support the idea of enforcing certain rules on commit messages.
Regarding squashing commits, it has pros and cons. I know in other
projects people keep all individual commits. I want to hear the
reason of our current practice of squashing commits.
Chen
On Thu, Sep 17, 2015 at 8:59 PM, Jianfeng Jia <ji...@gmail.com> wrote:
> Second the proposal first. It is a good way to track the git with jira.
>
> Another separate but related thought, since we enforce the commit message format, e.g. starting with jira ticket,
> can we just rebase but do NOT squash the commit when merging into the master?
> Then the commit is more atomic. It’s easy to pick/merge across the different branches.
>
> In my case, right now I’m facing the merging problem which is not only caused by the package name changes
> but also that my personal feature branches dependent on each other.
>
> Let’s say, I’m finishing working on A, and also I have ongoing branches B which is based on some parts of A.
> After review of A, all A’s commits are squashed to master. At that time I have to merge master to B,
> but git can’t find the shared part anymore. In contrast, it showed the false “conflicts” everywhere.
>
> If we keep the initial atomic commits, git will know the shared parts. And also, since we link the commits
> by ticket name, we don’t need to squash them together in order to know which commit is doing what.
> Does it make sense?
>
>
>> On Sep 17, 2015, at 8:15 PM, Chris Hillery <ch...@hillery.land> wrote:
>>
>> I implemented a process at Couchbase that can be used to validate whatever
>> we want about a proposed commit, including the form of the message. I could
>> do the same here, with some basic rules in place like "first line no longer
>> than 70 characters, blank line before any additional lines", etc. I could
>> also validate at least that if there IS a ticket associated with the
>> message, that it's in the right place and references an actual valid ticket.
>>
>> Ceej
>> aka Chris Hillery
>>
>> On Thu, Sep 17, 2015 at 8:12 PM, Ian Maxon <im...@uci.edu> wrote:
>>
>>> Sounds like a great idea to me. I was talking with Jianfeng in the
>>> hall about this today, and the idea came up that there might be a way
>>> to enforce this via a git hook or similar at Gerrit's end.
>>>
>>> Thoughts? I am not sure myself if this should be a strict rule (i.e.
>>> you must file tickets to commit) or if it should be on the burden of
>>> the reviewer to verify that.
>>>
>>> - Ian
>>>
>>> On Thu, Sep 17, 2015 at 1:39 PM, Taewoo Kim <wa...@gmail.com> wrote:
>>>> +1
>>>>
>>>> Best,
>>>> Taewoo
>>>>
>>>> On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <ec...@ucr.edu> wrote:
>>>>
>>>>> I like the proposal. This will be helpful when got and Jira are linked.
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Sep 17, 2015, at 1:14 PM, Chris Hillery <ch...@hillery.land>
>>>>> wrote:
>>>>>>
>>>>>> At Couchbase, we have a commit message standard which has proven
>>> useful.
>>>>>> All git commit messages must start with a short one-line summary of no
>>>>> more
>>>>>> than 60 characters or so. Then a blank line, followed by additional
>>>>>> details, specifics, etc. all on lines of no more than 72 characters.
>>> If
>>>>>> it's a simple enough change that the one-line summary is all you need,
>>>>>> that's fine too.
>>>>>>
>>>>>> Additionally, if the commit is for a specific ticket, that ticket
>>> number
>>>>>> must be at the beginning of the summary line, followed by a colon. FYI
>>>>> our
>>>>>> tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
>>>>>>
>>>>>> ------
>>>>>> ASTERIXDB-1097: Fix threading in printers
>>>>>>
>>>>>> Replace static data member with a safe thread-local instance to
>>>>>> avoid data corruption.
>>>>>> ------
>>>>>>
>>>>>> This really helps in tracking git history - there are several commands
>>>>>> which will only display the first line of a commit message, for
>>> instance,
>>>>>> so having it be self-contained makes it much easier to read. You may
>>> also
>>>>>> have noticed that Gerrit uses that first line for the subjects of
>>> emails
>>>>> it
>>>>>> sends out. Also, by including the ticket name, we can easily configure
>>>>>> Gerrit to provide a hyperlink to the ticket to make things easier to
>>>>> review.
>>>>>>
>>>>>> Here's a blog post which goes into excruciating detail about commit
>>>>>> messages:
>>>>>>
>>>>>> http://chris.beams.io/posts/git-commit/
>>>>>>
>>>>>> Ceej
>>>>>> aka Chris Hillery
>>>>>
>>>
>
>
>
> Best,
>
> Jianfeng Jia
> PhD Candidate of Computer Science
> University of California, Irvine
>
Re: Commit message proposal
Posted by Jianfeng Jia <ji...@gmail.com>.
Second the proposal first. It is a good way to track the git with jira.
Another separate but related thought, since we enforce the commit message format, e.g. starting with jira ticket,
can we just rebase but do NOT squash the commit when merging into the master?
Then the commit is more atomic. It’s easy to pick/merge across the different branches.
In my case, right now I’m facing the merging problem which is not only caused by the package name changes
but also that my personal feature branches dependent on each other.
Let’s say, I’m finishing working on A, and also I have ongoing branches B which is based on some parts of A.
After review of A, all A’s commits are squashed to master. At that time I have to merge master to B,
but git can’t find the shared part anymore. In contrast, it showed the false “conflicts” everywhere.
If we keep the initial atomic commits, git will know the shared parts. And also, since we link the commits
by ticket name, we don’t need to squash them together in order to know which commit is doing what.
Does it make sense?
> On Sep 17, 2015, at 8:15 PM, Chris Hillery <ch...@hillery.land> wrote:
>
> I implemented a process at Couchbase that can be used to validate whatever
> we want about a proposed commit, including the form of the message. I could
> do the same here, with some basic rules in place like "first line no longer
> than 70 characters, blank line before any additional lines", etc. I could
> also validate at least that if there IS a ticket associated with the
> message, that it's in the right place and references an actual valid ticket.
>
> Ceej
> aka Chris Hillery
>
> On Thu, Sep 17, 2015 at 8:12 PM, Ian Maxon <im...@uci.edu> wrote:
>
>> Sounds like a great idea to me. I was talking with Jianfeng in the
>> hall about this today, and the idea came up that there might be a way
>> to enforce this via a git hook or similar at Gerrit's end.
>>
>> Thoughts? I am not sure myself if this should be a strict rule (i.e.
>> you must file tickets to commit) or if it should be on the burden of
>> the reviewer to verify that.
>>
>> - Ian
>>
>> On Thu, Sep 17, 2015 at 1:39 PM, Taewoo Kim <wa...@gmail.com> wrote:
>>> +1
>>>
>>> Best,
>>> Taewoo
>>>
>>> On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <ec...@ucr.edu> wrote:
>>>
>>>> I like the proposal. This will be helpful when got and Jira are linked.
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Sep 17, 2015, at 1:14 PM, Chris Hillery <ch...@hillery.land>
>>>> wrote:
>>>>>
>>>>> At Couchbase, we have a commit message standard which has proven
>> useful.
>>>>> All git commit messages must start with a short one-line summary of no
>>>> more
>>>>> than 60 characters or so. Then a blank line, followed by additional
>>>>> details, specifics, etc. all on lines of no more than 72 characters.
>> If
>>>>> it's a simple enough change that the one-line summary is all you need,
>>>>> that's fine too.
>>>>>
>>>>> Additionally, if the commit is for a specific ticket, that ticket
>> number
>>>>> must be at the beginning of the summary line, followed by a colon. FYI
>>>> our
>>>>> tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
>>>>>
>>>>> ------
>>>>> ASTERIXDB-1097: Fix threading in printers
>>>>>
>>>>> Replace static data member with a safe thread-local instance to
>>>>> avoid data corruption.
>>>>> ------
>>>>>
>>>>> This really helps in tracking git history - there are several commands
>>>>> which will only display the first line of a commit message, for
>> instance,
>>>>> so having it be self-contained makes it much easier to read. You may
>> also
>>>>> have noticed that Gerrit uses that first line for the subjects of
>> emails
>>>> it
>>>>> sends out. Also, by including the ticket name, we can easily configure
>>>>> Gerrit to provide a hyperlink to the ticket to make things easier to
>>>> review.
>>>>>
>>>>> Here's a blog post which goes into excruciating detail about commit
>>>>> messages:
>>>>>
>>>>> http://chris.beams.io/posts/git-commit/
>>>>>
>>>>> Ceej
>>>>> aka Chris Hillery
>>>>
>>
Best,
Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine
Re: Commit message proposal
Posted by Till Westmann <ti...@apache.org>.
I’ve added this to the other proposed formatting rules on the Wiki
[1].
[1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
On 28 Sep 2015, at 9:47, Till Westmann wrote:
> Good point :)
>
> I think that we might be able to get to really short messages, but
> it’s certainly not very convenient.
> The other question is, if we need to prefix the summary with the issue
> number or if we just need to have the issue number somewhere.
> Thoughts on this?
>
> Thanks,
> Till
>
> On 27 Sep 2015, at 23:38, Chris Hillery wrote:
>
>> It's a good goal... although since our Jira project name is so
>> lengthy,
>> after starting a commit message with "ASTERIXDB-123: " you would only
>> have
>> 35 characters left for your summary. Do we think that's feasible?
>>
>> Ceej
Re: Commit message proposal
Posted by Till Westmann <ti...@apache.org>.
Good point :)
I think that we might be able to get to really short messages, but
it’s certainly not very convenient.
The other question is, if we need to prefix the summary with the issue
number or if we just need to have the issue number somewhere.
Thoughts on this?
Thanks,
Till
On 27 Sep 2015, at 23:38, Chris Hillery wrote:
> It's a good goal... although since our Jira project name is so
> lengthy,
> after starting a commit message with "ASTERIXDB-123: " you would only
> have
> 35 characters left for your summary. Do we think that's feasible?
>
> Ceej
Re: Commit message proposal
Posted by Chris Hillery <ch...@hillery.land>.
It's a good goal... although since our Jira project name is so lengthy,
after starting a commit message with "ASTERIXDB-123: " you would only have
35 characters left for your summary. Do we think that's feasible?
Ceej
Re: Commit message proposal
Posted by Till Westmann <ti...@apache.org>.
A common guideline for the first line seems to be 50 characters (and
wrapping the rest at 72) [1,2,3].
Is there a reason why we wouldn’t use that rule (if we use one)?
Cheers,
Till
[1] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
[2]
https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
[3] http://chris.beams.io/posts/git-commit/
On 17 Sep 2015, at 20:15, Chris Hillery wrote:
> I implemented a process at Couchbase that can be used to validate
> whatever
> we want about a proposed commit, including the form of the message. I
> could
> do the same here, with some basic rules in place like "first line no
> longer
> than 70 characters, blank line before any additional lines", etc. I
> could
> also validate at least that if there IS a ticket associated with the
> message, that it's in the right place and references an actual valid
> ticket.
>
> Ceej
> aka Chris Hillery
>
> On Thu, Sep 17, 2015 at 8:12 PM, Ian Maxon <im...@uci.edu> wrote:
>
>> Sounds like a great idea to me. I was talking with Jianfeng in the
>> hall about this today, and the idea came up that there might be a way
>> to enforce this via a git hook or similar at Gerrit's end.
>>
>> Thoughts? I am not sure myself if this should be a strict rule (i.e.
>> you must file tickets to commit) or if it should be on the burden of
>> the reviewer to verify that.
>>
>> - Ian
>>
>> On Thu, Sep 17, 2015 at 1:39 PM, Taewoo Kim <wa...@gmail.com>
>> wrote:
>>> +1
>>>
>>> Best,
>>> Taewoo
>>>
>>> On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <ec...@ucr.edu>
>>> wrote:
>>>
>>>> I like the proposal. This will be helpful when got and Jira are
>>>> linked.
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Sep 17, 2015, at 1:14 PM, Chris Hillery <ch...@hillery.land>
>>>> wrote:
>>>>>
>>>>> At Couchbase, we have a commit message standard which has proven
>> useful.
>>>>> All git commit messages must start with a short one-line summary
>>>>> of no
>>>> more
>>>>> than 60 characters or so. Then a blank line, followed by
>>>>> additional
>>>>> details, specifics, etc. all on lines of no more than 72
>>>>> characters.
>> If
>>>>> it's a simple enough change that the one-line summary is all you
>>>>> need,
>>>>> that's fine too.
>>>>>
>>>>> Additionally, if the commit is for a specific ticket, that ticket
>> number
>>>>> must be at the beginning of the summary line, followed by a colon.
>>>>> FYI
>>>> our
>>>>> tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
>>>>>
>>>>> ------
>>>>> ASTERIXDB-1097: Fix threading in printers
>>>>>
>>>>> Replace static data member with a safe thread-local instance to
>>>>> avoid data corruption.
>>>>> ------
>>>>>
>>>>> This really helps in tracking git history - there are several
>>>>> commands
>>>>> which will only display the first line of a commit message, for
>> instance,
>>>>> so having it be self-contained makes it much easier to read. You
>>>>> may
>> also
>>>>> have noticed that Gerrit uses that first line for the subjects of
>> emails
>>>> it
>>>>> sends out. Also, by including the ticket name, we can easily
>>>>> configure
>>>>> Gerrit to provide a hyperlink to the ticket to make things easier
>>>>> to
>>>> review.
>>>>>
>>>>> Here's a blog post which goes into excruciating detail about
>>>>> commit
>>>>> messages:
>>>>>
>>>>> http://chris.beams.io/posts/git-commit/
>>>>>
>>>>> Ceej
>>>>> aka Chris Hillery
>>>>
>>
Re: Commit message proposal
Posted by Chris Hillery <ch...@hillery.land>.
I implemented a process at Couchbase that can be used to validate whatever
we want about a proposed commit, including the form of the message. I could
do the same here, with some basic rules in place like "first line no longer
than 70 characters, blank line before any additional lines", etc. I could
also validate at least that if there IS a ticket associated with the
message, that it's in the right place and references an actual valid ticket.
Ceej
aka Chris Hillery
On Thu, Sep 17, 2015 at 8:12 PM, Ian Maxon <im...@uci.edu> wrote:
> Sounds like a great idea to me. I was talking with Jianfeng in the
> hall about this today, and the idea came up that there might be a way
> to enforce this via a git hook or similar at Gerrit's end.
>
> Thoughts? I am not sure myself if this should be a strict rule (i.e.
> you must file tickets to commit) or if it should be on the burden of
> the reviewer to verify that.
>
> - Ian
>
> On Thu, Sep 17, 2015 at 1:39 PM, Taewoo Kim <wa...@gmail.com> wrote:
> > +1
> >
> > Best,
> > Taewoo
> >
> > On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <ec...@ucr.edu> wrote:
> >
> >> I like the proposal. This will be helpful when got and Jira are linked.
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >> > On Sep 17, 2015, at 1:14 PM, Chris Hillery <ch...@hillery.land>
> >> wrote:
> >> >
> >> > At Couchbase, we have a commit message standard which has proven
> useful.
> >> > All git commit messages must start with a short one-line summary of no
> >> more
> >> > than 60 characters or so. Then a blank line, followed by additional
> >> > details, specifics, etc. all on lines of no more than 72 characters.
> If
> >> > it's a simple enough change that the one-line summary is all you need,
> >> > that's fine too.
> >> >
> >> > Additionally, if the commit is for a specific ticket, that ticket
> number
> >> > must be at the beginning of the summary line, followed by a colon. FYI
> >> our
> >> > tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
> >> >
> >> > ------
> >> > ASTERIXDB-1097: Fix threading in printers
> >> >
> >> > Replace static data member with a safe thread-local instance to
> >> > avoid data corruption.
> >> > ------
> >> >
> >> > This really helps in tracking git history - there are several commands
> >> > which will only display the first line of a commit message, for
> instance,
> >> > so having it be self-contained makes it much easier to read. You may
> also
> >> > have noticed that Gerrit uses that first line for the subjects of
> emails
> >> it
> >> > sends out. Also, by including the ticket name, we can easily configure
> >> > Gerrit to provide a hyperlink to the ticket to make things easier to
> >> review.
> >> >
> >> > Here's a blog post which goes into excruciating detail about commit
> >> > messages:
> >> >
> >> > http://chris.beams.io/posts/git-commit/
> >> >
> >> > Ceej
> >> > aka Chris Hillery
> >>
>
Re: Commit message proposal
Posted by Ian Maxon <im...@uci.edu>.
Sounds like a great idea to me. I was talking with Jianfeng in the
hall about this today, and the idea came up that there might be a way
to enforce this via a git hook or similar at Gerrit's end.
Thoughts? I am not sure myself if this should be a strict rule (i.e.
you must file tickets to commit) or if it should be on the burden of
the reviewer to verify that.
- Ian
On Thu, Sep 17, 2015 at 1:39 PM, Taewoo Kim <wa...@gmail.com> wrote:
> +1
>
> Best,
> Taewoo
>
> On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <ec...@ucr.edu> wrote:
>
>> I like the proposal. This will be helpful when got and Jira are linked.
>>
>>
>>
>> Sent from my iPhone
>>
>> > On Sep 17, 2015, at 1:14 PM, Chris Hillery <ch...@hillery.land>
>> wrote:
>> >
>> > At Couchbase, we have a commit message standard which has proven useful.
>> > All git commit messages must start with a short one-line summary of no
>> more
>> > than 60 characters or so. Then a blank line, followed by additional
>> > details, specifics, etc. all on lines of no more than 72 characters. If
>> > it's a simple enough change that the one-line summary is all you need,
>> > that's fine too.
>> >
>> > Additionally, if the commit is for a specific ticket, that ticket number
>> > must be at the beginning of the summary line, followed by a colon. FYI
>> our
>> > tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
>> >
>> > ------
>> > ASTERIXDB-1097: Fix threading in printers
>> >
>> > Replace static data member with a safe thread-local instance to
>> > avoid data corruption.
>> > ------
>> >
>> > This really helps in tracking git history - there are several commands
>> > which will only display the first line of a commit message, for instance,
>> > so having it be self-contained makes it much easier to read. You may also
>> > have noticed that Gerrit uses that first line for the subjects of emails
>> it
>> > sends out. Also, by including the ticket name, we can easily configure
>> > Gerrit to provide a hyperlink to the ticket to make things easier to
>> review.
>> >
>> > Here's a blog post which goes into excruciating detail about commit
>> > messages:
>> >
>> > http://chris.beams.io/posts/git-commit/
>> >
>> > Ceej
>> > aka Chris Hillery
>>
Re: Commit message proposal
Posted by Taewoo Kim <wa...@gmail.com>.
+1
Best,
Taewoo
On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <ec...@ucr.edu> wrote:
> I like the proposal. This will be helpful when got and Jira are linked.
>
>
>
> Sent from my iPhone
>
> > On Sep 17, 2015, at 1:14 PM, Chris Hillery <ch...@hillery.land>
> wrote:
> >
> > At Couchbase, we have a commit message standard which has proven useful.
> > All git commit messages must start with a short one-line summary of no
> more
> > than 60 characters or so. Then a blank line, followed by additional
> > details, specifics, etc. all on lines of no more than 72 characters. If
> > it's a simple enough change that the one-line summary is all you need,
> > that's fine too.
> >
> > Additionally, if the commit is for a specific ticket, that ticket number
> > must be at the beginning of the summary line, followed by a colon. FYI
> our
> > tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
> >
> > ------
> > ASTERIXDB-1097: Fix threading in printers
> >
> > Replace static data member with a safe thread-local instance to
> > avoid data corruption.
> > ------
> >
> > This really helps in tracking git history - there are several commands
> > which will only display the first line of a commit message, for instance,
> > so having it be self-contained makes it much easier to read. You may also
> > have noticed that Gerrit uses that first line for the subjects of emails
> it
> > sends out. Also, by including the ticket name, we can easily configure
> > Gerrit to provide a hyperlink to the ticket to make things easier to
> review.
> >
> > Here's a blog post which goes into excruciating detail about commit
> > messages:
> >
> > http://chris.beams.io/posts/git-commit/
> >
> > Ceej
> > aka Chris Hillery
>
Re: Commit message proposal
Posted by Eldon Carman <ec...@ucr.edu>.
I like the proposal. This will be helpful when got and Jira are linked.
Sent from my iPhone
> On Sep 17, 2015, at 1:14 PM, Chris Hillery <ch...@hillery.land> wrote:
>
> At Couchbase, we have a commit message standard which has proven useful.
> All git commit messages must start with a short one-line summary of no more
> than 60 characters or so. Then a blank line, followed by additional
> details, specifics, etc. all on lines of no more than 72 characters. If
> it's a simple enough change that the one-line summary is all you need,
> that's fine too.
>
> Additionally, if the commit is for a specific ticket, that ticket number
> must be at the beginning of the summary line, followed by a colon. FYI our
> tickets in Jira are named eg. ASTERIXDB-1097. So, for example:
>
> ------
> ASTERIXDB-1097: Fix threading in printers
>
> Replace static data member with a safe thread-local instance to
> avoid data corruption.
> ------
>
> This really helps in tracking git history - there are several commands
> which will only display the first line of a commit message, for instance,
> so having it be self-contained makes it much easier to read. You may also
> have noticed that Gerrit uses that first line for the subjects of emails it
> sends out. Also, by including the ticket name, we can easily configure
> Gerrit to provide a hyperlink to the ticket to make things easier to review.
>
> Here's a blog post which goes into excruciating detail about commit
> messages:
>
> http://chris.beams.io/posts/git-commit/
>
> Ceej
> aka Chris Hillery
Re: Commit message proposal
Posted by Till Westmann <ti...@apache.org>.
On 6 Oct 2015, at 15:43, Chris Hillery wrote:
> On Thu, Sep 17, 2015 at 1:14 PM, Chris Hillery <ch...@hillery.land>
> wrote:
>
>> Also, by including the ticket name, we can easily configure Gerrit to
>> provide a hyperlink to the ticket to make things easier to review.
>>
>
> Just FYI, I've configured Gerrit to do this; see
> https://asterix-gerrit.ics.uci.edu/#/c/432/ for an example.
Fancy - and less than 50 chars :)
Cheers,
Till
Re: Commit message proposal
Posted by Chris Hillery <ch...@hillery.land>.
On Thu, Sep 17, 2015 at 1:14 PM, Chris Hillery <ch...@hillery.land>
wrote:
> Also, by including the ticket name, we can easily configure Gerrit to
> provide a hyperlink to the ticket to make things easier to review.
>
Just FYI, I've configured Gerrit to do this; see
https://asterix-gerrit.ics.uci.edu/#/c/432/ for an example.
Ceej
aka Chris Hillery