asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Westmann" <>
Subject Re: Commit message proposal
Date Fri, 18 Sep 2015 05:48:20 GMT
+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,

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 <> 
> 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 <> 
>>> 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
>>>>>>> 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
>>>>>>> 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.
>>>>>>> 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:
>>>>>>> Ceej
>>>>>>> aka Chris Hillery
>> Best,
>> Jianfeng Jia
>> PhD Candidate of Computer Science
>> University of California, Irvine

View raw message