asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chen Li <che...@gmail.com>
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.

Chen

On Thu, Sep 17, 2015 at 8:59 PM, Jianfeng Jia <jianfeng.jia@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 <chillery@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 <imaxon@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 <wangsaeu@gmail.com> wrote:
>>>> +1
>>>>
>>>> Best,
>>>> Taewoo
>>>>
>>>> On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <ecarm002@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 <chillery@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
>

Mime
View raw message