> > For example, I think we should better not add some git hooks that are > executed based on some environments
I agree, it should be discussed. My opinion is git-cz is enough. It won't let developers can't use git GUI tools, only provide a convenient guidance on how to write a correct commit msg in command line. On Mon, Sep 2, 2019 at 7:04 PM SHUANG SU <sushuang0...@gmail.com> wrote: > Specifically, I think the toolchain should better not depend on more > environment-dependent settings. > Otherwise, it probably brings some burdens. > For example, I think we should better not add some git hooks that are > executed based on some environments > like Nodejs. Otherwise, developers might have to config the environment in > variable git GUI tools. > (I am not totally sure about that, just has some bad experience before). > > ------------------------------ > Su Shuang (100pah) > ------------------------------ > > > > On Mon, 2 Sep 2019 at 18:45, Yi Shen <shenyi....@gmail.com> wrote: > >> About (2) basically my point is we should not bring more burden to >>> contributors in the installation and configuration of this the project. >>> >> >> I think toolchain is necessary and helpful for improving developing >> experience. It's not a burden. >> >> 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. >>>>>> >>>>> >> >> -- >> Yi Shen >> Senior Developer >> Baidu, Inc. >> > -- Yi Shen Senior Developer Baidu, Inc.
