Thanks for the reminder, I'll start a VOTE thread.

Best wishes!
Calvin Kirs


On 01/27/2022 22:39,Alexander Alten<[email protected]> wrote:
Hi team,

We should start a vote on that, since ht procedure affects our community. 
Calvin, can you as initiator please start the voting process?

Cheers,
—Alex


On 27. Jan 2022, at 14:57, CalvinKirs <[email protected]> wrote:

Hi guys,
Thanks for all discuss, this discussion has been going on for a long time, I 
will close this discussion thread, we will use Squash And Merge on the main 
branch, other branches use Merge PullRequest.


Best wishes!
Calvin Kirs


On 01/18/2022 14:32,CalvinKirs<[email protected]> wrote:
Hi guys,


Thanks all discuss, use Squash And Merge on the main branch, other branches use 
Merge PullRequest.
(Using Squash Merge generally does not lose log information, but when a big PR 
is submitted, the log information is not clear and distinct, because this time, 
all file submissions are a log list.)


Can we reach a consensus on this?


Best wishes!
Calvin Kirs


On 01/16/2022 18:20,Jean-Baptiste Onofre<[email protected]> wrote:
Hi,

What I’m using in most of Apache project:

- squash and merge on main branch
- cherry pick and/or merge PR on other branches.

What I like in merge commit is that you have the initial author and the 
committer who merged.

Regards
JB

Le 14 janv. 2022 à 06:09, CalvinKirs <[email protected]> a écrit :

Hi guys,


Currently, we have three ways to merge codes, we mostly use create a merge, 
squash merge.

I suggest we use Squash Merge.

As you work on a feature branch, you often create small, self-contained 
commits. These small commits help describe the process of building a feature 
but can clutter your Git history after the feature is finished. As you finish 
features, you can combine these commits and ensure a cleaner merge history in 
your Git repository by using the squash and merge strategy.

And Create a Merge can cause our Git log to get messy and even lose some of our 
git log (override).

If we encounter a large PR, we should split it up instead of creating a large 
PR (which will result in a huge review effort, and if there are too many 
issues, it will also result in a delayed merge of the PR, or even frequent code 
conflicts), and then use Create a merge to merge it.

We can also see that most Apache projects will force the Squash Merge approach, 
so I hope the community can reach a consensus, and if you have different 
opinions, feel free to discuss.


Best wishes!
Calvin Kirs

Reply via email to