asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hillery <chill...@hillery.land>
Subject Re: Commit message proposal
Date Fri, 18 Sep 2015 03:15:44 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message