asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chen Li <>
Subject Re: Commit message proposal
Date Fri, 18 Sep 2015 05:08:48 GMT
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.


On Thu, Sep 17, 2015 at 8:59 PM, Jianfeng Jia <> 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”
> 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 <> 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 <> 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 <> wrote:
>>>> +1
>>>> Best,
>>>> Taewoo
>>>> On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <> 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 <>
>>>>> 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
>>>>>> 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.
>>>>> 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
>>> 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
>>>>> review.
>>>>>> Here's a blog post which goes into excruciating detail about commit
>>>>>> messages:
>>>>>> Ceej
>>>>>> aka Chris Hillery
> Best,
> Jianfeng Jia
> PhD Candidate of Computer Science
> University of California, Irvine

View raw message