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 <[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
