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