(2) This will not cause any trouble because we only provide a configure file of git-cz and it works pretty much like ".editorconfig". If the user is used to git-cz and use it with our project, it can use cz-cli to generate commit message. If not, he can still manually commit following our guidelines.
(3) In most cases, the improvement in a single pull request won't be too large. As stated in GitHub's blog, > While merge commits retain commits like “oops missed a spot” and “maybe fix that test? [round 2]”, squashing retains the changes but omits the individual commits from history. Many people prefer this workflow because, while those work-in-progress commits are helpful when working on a feature branch, they aren’t necessarily important to retain when looking at the history of your base branch. And if we do wish to keep track of the commit history, we can also add the pull request id in the squashed message footer like: fix(svg): change the default behavior of download image with toolbox; fix #12345; (blank line) - x feature - y feature - z feature (blank line) squashed in #778899 where #778899 is the pull request id. Wenli On Mon, Sep 2, 2019 at 6:38 PM SHUANG SU <sushuang0...@gmail.com> wrote: > +1 > > But, > About (2) basically my point is we should not bring more burden to > contributors in the installation and configuration of this the project. > About (3) I have no experience with squashing PR. So I am not sure whether > squashing is OK in some complicated commit log three, > for example, when the branch contains lots of merging in the commit > history. Is that OK in those cases? > > ------------------------------ > Su Shuang (100pah) > ------------------------------ > > > > On Mon, 2 Sep 2019 at 16:58, yufeng <yu_fen...@qq.com> wrote: > >> +1 >> >> ------------------------------ >> 发自我的iPhone >> >> >> ------------------ Original ------------------ >> *From:* Ovilia <oviliazh...@gmail.com> >> *Date:* Mon,Sep 2,2019 3:16 PM >> *To:* dev <dev@echarts.apache.org> >> *Subject:* Re: [VOTE] Git message guidelines >> >> Let's have a vote on this. >> >> If you agree on the following guidelines, please +1. >> >> 1. Based on the Angular.js git message guidelines [1], and change about >> the issue number part, making it something like: >> >> fix(svg): change the default behavior of download image with >> toolbox; fix #12345 >> >> 2. We may provide tools like cz-cli [2] to help developers to commit >> using this guidelines, but it's not compulsory. >> >> 3. When commits are made from pull requests from the community, who >> didn't follow the guidelines, we should use "squash and commit" when >> merging and commit using guidelines. >> >> [1] >> https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines >> [2] https://github.com/commitizen/cz-cli >> >> Wenli >> >> >> On Sat, Aug 31, 2019 at 4:37 PM Ovilia <oviliazh...@gmail.com> wrote: >> >>> If developers are not ussing our git message guidelines, we can still >>> squash the commits into a single one and edit message by ourselves. >>> >>> Wenli >>> >>> >>> On Fri, Aug 30, 2019 at 9:57 PM Yi Shen <shenyi....@gmail.com> wrote: >>> >>>> Agree with the guidelines. >>>> >>>> those tools, like "git-cz", bring more troubles than benefits >>>>> >>>> >>>> We should use tools like commitizen[1] to help us write good commits >>>> message. >>>> >>>> I guess we can't force developers to use tools like 'git-cz' to >>>> validate the commits in their pull requests? >>>> >>>> [1] https://github.com/commitizen/cz-cli >>>> >>>> On Fri, Aug 30, 2019 at 6:11 PM SHUANG SU <sushuang0...@gmail.com> >>>> wrote: >>>> >>>>> I agree with that commit message should follow a guideline, which will >>>>> also make changelog collection work easy. >>>>> >>>>> But I suggest that do not use some tool to force us to commit like >>>>> that. In my experience, those tools, like "git-cz", >>>>> bring more troubles than benefits, especially when developers using >>>>> some git GUI tools, always >>>>> some error throws so that developers have to find how to config to >>>>> avoid that. >>>>> >>>>> >>>>> ------------------------------ >>>>> Su Shuang (100pah) >>>>> ------------------------------ >>>>> >>>>> >>>>> >>>>> On Fri, 30 Aug 2019 at 17:57, Ovilia <oviliazh...@gmail.com> wrote: >>>>> >>>>>> Currently, we do not have a standard for git message guidelines, so >>>>>> the commit logs may look a little untidy [1]. >>>>>> >>>>>> A very popular commit guideline is from Angular.js [2], which I think >>>>>> is very nice only that it includes issue number at the footer. >>>>>> For example, with Angular.js's commit guideline, a commit message may >>>>>> be: >>>>>> fix(svg): change the default behavior of download image with toolbox >>>>>> fix #12345 >>>>>> >>>>>> I think putting the issue number at the end of the subject may be a >>>>>> better idea. >>>>>> Because if the issue number is not included in the first line, it >>>>>> will only be visible when "..." is clicked. >>>>>> Issue number, and more importantly, the link to the issue is a very >>>>>> important part of a git message. >>>>>> >>>>>> >>>>>> My suggest is, to follow the Angular.js git message guidelines, and >>>>>> change about the issue number part, making it something like: >>>>>> >>>>>> fix(svg): change the default behavior of download image with >>>>>> toolbox; fix #12345 >>>>>> >>>>>> >>>>>> [1] https://github.com/apache/incubator-echarts/commits/master >>>>>> [2] >>>>>> https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines >>>>>> >>>>>> Wenli >>>>>> >>>>> >>>> >>>> -- >>>> Yi Shen >>>> Senior Developer >>>> Baidu, Inc. >>>> >>>
