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> > > >> > >> >
