I have changed mail setting :) Let us try to use `Squash and merge` & `Rebase and merge` , we’d like to share the experience each other.
------------------ Zhao Jun Apache Sharding-Sphere & ServiceComb > On Nov 23, 2018, at 12:07 PM, 吴晟 Sheng Wu <[email protected]> wrote: > > I am not sure whether `rebase and merge` to avoid scenario(1) or not. `make > commit log more clear` is what we try our best to do. > > > Also remind again, please change the mail name setting, to let others know > who is talking :) > > > ------------------ > Sheng Wu > Apache SkyWalking & Sharding-Sphere > > > > > > > > ------------------ Original ------------------ > From: "cherrylzhao"<[email protected]>; > Date: Fri, Nov 23, 2018 11:59 AM > To: "dev"<[email protected]>; > > Subject: Re: Recommand to open `Squash and merge` as default merge > inGitHubrepo > > > > Thanks a lot :) > > I have exactly understood what keep `squash` in default `commit merge` is > available mean. > Also we should use rebase to make commit log more clear and reliable. > > >> On Nov 23, 2018, at 11:11 AM, 吴晟 Sheng Wu <[email protected]> wrote: >> >> I have no doubt our initial committers could do this well. But I suggest >> this because of new contributors. Let's think in this scenarios >> >> >> 1. A new contributor, and new to GitHub. We checkout his fork and send pull >> request. But he didn't bind this GitHub mail to his local git. Then if this >> PR merged, you will lose the visible way to track his contributions. GitHub >> will not show him in the contributor list. >> 2. A pull request is complex in some ways, and got reviewed/change requests >> by many times, so the PR author change codes a lot of times. Then how should >> we merge this PR? Ask him to rebase, or we don't merge? Or merge this by >> bring several dozens times commits, which will make our revalue more >> different. >> >> >> Both of these came from SkyWalking's experience, so, as soon as >> ShardingSphere joined the Incubator, I am sharing this for you. Also, you >> should know, this is the common ways in many Open Source projects. >> >> >> ------------------ >> Sheng Wu >> Apache SkyWalking & Sharding-Sphere >> >> >> >> >> >> >> >> ------------------ Original ------------------ >> From: "cherrylzhao"<[email protected]>; >> Date: Fri, Nov 23, 2018 09:24 AM >> To: "dev"<[email protected]>; >> >> Subject: Re: Recommand to open `Squash and merge` as default merge in >> GitHubrepo >> >> >> >> In fact, we also use dev branch to add new feature like GitHub issue #1238. >> Usually we make issue id related with commit comment. `squash and merge` >> maybe not suitable for this scenario. >> I think we should make commit much smaller and organized by functions or >> modification purpose is better like Willem said. >> Also we can rebase the commit count if the content is not clear. >> >> On 2018/11/22 10:38:43, "[email protected]" <[email protected]> wrote: >>> Yes, right now ShardingShpere always use `dev` branch, and other branch> >>> just for temporary proposal. We can try to use `squash and merge`.> >>> >>> ------------------> >>> >>> Liang Zhang (John)> >>> Apache Sharding-Sphere & Dubbo> >>> >>> >>> Sheng Wu <[email protected]> 于2018年11月22日周四 下午3:19写道：> >>> >>>>> But if we have multiple branches and we need to cherry pick the patch> >>>>> between two different branch. It could be better if the commits is> >>>>> much smaller and organized by the functions or the modification> >>>>> purposes.> >>>>> >>>> Agree. But just fit for multiple branches in maintaining. So keep >>>> `squash`> >>>> in default, `commit merge` available is a good choice.> >>>>> >>>> For ShardingSphere, I don't see that is happening.> >>>>> >>>> Sheng Wu.> >>>>> >>>> On 2018/11/22 03:21:33, Willem Jiang <[email protected]> wrote:> >>>>> If the commits are only for fixing the PR review, I think 'sqash and> >>>>> merge' is good way to go.> >>>>> But if we have multiple branches and we need to cherry pick the patch> >>>>> between two different branch. It could be better if the commits is> >>>>> much smaller and organized by the functions or the modification> >>>>> purposes.> >>>>>> >>>>> Willem Jiang> >>>>>> >>>>> Twitter: willemjiang> >>>>> Weibo: 姜宁willem> >>>>>> >>>>> On Wed, Nov 21, 2018 at 11:02 PM 吴晟 Sheng Wu <[email protected]>> >>>> wrote:> >>>>>>> >>>>>> Hi, initial committer> >>>>>>> >>>>>>> >>>>>> I have known, we are going to move the repos. I think we could expect> >>>> ShardingSphere will have more and more contributors from out of initial> >>>> committer team. In our Apache releases, we need to provide CHANGELOGS, >>>> ref> >>>> SkyWalking's[1]. We should make commit logs matching the issues and> >>>> changelogs.> >>>>>>> >>>>>>> >>>>>> Also, in the future, we need to evaluate new committer and PPMC,> >>>> `squash and merge`makes your commits[2] list more reliable. Because in my> >>>> personal experiences, some one will submit a lot of commits in PR. Others> >>>> will rebase, especially the one has more open source experiences. Make> >>>> commits at least equal the number of PR merged.> >>>>>>> >>>>>>> >>>>>> Of course, this is only my suggestion.> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> [1] https://github.com/apache/incubator-skywalking/blob/5.x/CHANGES.md> >>>>>> [2]> >>>> https://github.com/sharding-sphere/sharding-sphere/graphs/contributors> >>>>>>> >>>>>>> >>>>>> ------------------> >>>>>> Sheng Wu> >>>>>> Apache SkyWalking & Sharding-Sphere> >>>>>>
