Hi Tibor, On 5.08.2025 16:00, Tibor Digana wrote: > Is somebody using Git Merge? For sake of clarity of the log history, this > should be prohibited and Git Rebase should be used instead. This > alternative should be added in the Vote as well.
Good topic! I think another interesting feature to discuss is requiring commit signatures (GPG or SSH) on all commits. This creates a verifiable trail showing that commits came from specific GitHub users, although that trail disappears if the user later removes the associated key from their account. The two topics are related: - Merge commits preserve signatures of all included changes, and the merge commit itself is signed by GitHub. However, as you noted, this can result in a cluttered history with “apply review suggestions” and other small technical commits and a very branched tree. - GitHub’s "Rebase" button removes the branching issue but discards the original commit signatures. If I recall correctly, with “verified mode” enabled, rebased commits are marked as *partially verified*. - Squash merges also discard original signatures but combine the PR into a single commit. Unless the PR is co-authored, GitHub marks that commit as “verified.” This is the option I use most often. That said, “merge” still has its place: for example, when merging release branches. In Log4j, we typically create a `release/x.y.z` branch just before a release for final adjustments, then merge it back afterward. The “rebase” button is probably my favorite one, as it breaks signatures and does not remove “apply review suggestions” commits. The improvement in the Git tree structure isn't really tangible. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
