asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jianfeng Jia <>
Subject Re: Commit message proposal
Date Fri, 18 Sep 2015 03:59:17 GMT
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
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 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:
>>>>> Ceej
>>>>> aka Chris Hillery


Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message