+1 on the commit messages (but I think that we don't necessarily need to
have a tool check it).
Wrt the squashed commits, the reason for me to prefer them is, that one
gets a nice and understandable history on the master branch. With
several commits - even if they are linked in some way - it gets much
harder to understand what the complete change is that was done to fix a
problem. Especially if there are several rounds of reviews and fixes, it
seems not very useful (from a human perspective) to keep all the
intermediate commits in the history.
Now I also never had the problem of several dependent feature branches,
so I might not appreciate the problem enough.
My 2c,
Till
On 17 Sep 2015, at 22:08, Chen Li wrote:
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 <[email protected]>
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 <[email protected]>
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
Best,
Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine
