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