asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Westmann" <ti...@apache.org>
Subject Re: Commit message proposal
Date Sun, 27 Sep 2015 22:14:59 GMT
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 <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
>>>>
>>

Mime
View raw message