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 <[email protected]> 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 <[email protected]> wrote: > > +1 > > > > Best, > > Taewoo > > > > On Thu, Sep 17, 2015 at 1:26 PM, Eldon Carman <[email protected]> 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 <[email protected]> > >> 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 > >> >
