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 >
