+1 for the proposal Regardless of the defaults, every committer should ensure that title and body of the merged commit accurately reflects its diff.
-Max On Mon, Aug 3, 2026 at 9:48 PM Kevin Liu <[email protected]> wrote: > > I was initially proposing to change the setting for both the PR title and > body. But I think you're right, changing the pr body setting will create too > much noise. > > Let's start by changing the PR title setting only, from `COMMIT_OR_PR_TITLE` > to `PR_TITLE` (always use the PR title, even for 1 commit PR). > Let's leave the PR body setting as is. This means > - 1 commit in the PR → body is the commit's message. > - 2 or more commits in the PR → body contains the list of commit messages > > Best, > Kevin Liu > > On Mon, Aug 3, 2026 at 11:50 AM Daniel Weeks <[email protected]> wrote: >>> >>> I'll work with ASF Infra to change the setting to use PR body and PR title >> >> >> Just want to double check, you didn't mean PR body, right? (like the >> description of the PR). That would be way too much to include in a commit >> message. >> >> I'm actually not clear on where this landed. >> >> -Dan >> >> On Mon, Aug 3, 2026 at 11:38 AM Kevin Liu <[email protected]> wrote: >>> >>> > At the same time, I'd encourage every committer to do a quick sanity >>> > check before merging. Rules help, but ultimately it's people who make the >>> > difference. >>> >>> Agree 100% :) >>> >>> > 1 commit in the PR → the default squash commit title is that commit's >>> > title, and the body is that commit's message. >>> >>> This is the scary case. The default is not what I would expect at all. >>> >>> >>> Seems like we have broad support, and this is a fairly non-controversial >>> change. I'll work with ASF Infra to change the setting to use PR body and >>> PR title. That'll be a good starting point and it is ultimately up to the >>> person merging to make sure the final commit reads well in git log. >>> >>> Thanks everyone! >>> >>> >>> On Mon, Aug 3, 2026 at 11:27 AM Hongyue Zhang <[email protected]> >>> wrote: >>>> >>>> +1 on the proposal but echo Yufei's take on more committer attention >>>> required on PR merge. >>>> >>>> Two things worth checking: >>>> 1. PR titles can arrive truncated like #17360 but committers can help >>>> rewrite at merge. >>>> 2. PR bodies carry more content than typical commit bodies, like >>>> @dependabot usually bring the embedded html and sometimes @mentions. Those >>>> markup does not tend to read well in git log. >>>> >>>> Hongyue Zhang >>>> >>>> On Mon, Aug 3, 2026 at 10:41 AM Yufei Gu <[email protected]> wrote: >>>>> >>>>> About three years ago, I worked with Anton on a few PRs. Before merging, >>>>> he always reviewed everything carefully, including the PR title, and made >>>>> any necessary changes. I think that's a good habit to continue, so I've >>>>> tried to do the same. >>>>> >>>>> I'm supportive of having an explicit rule for things like this. At the >>>>> same time, I'd encourage every committer to do a quick sanity check >>>>> before merging. Rules help, but ultimately it's people who make the >>>>> difference. >>>>> >>>>> Yufei >>>>> >>>>> >>>>> On Mon, Aug 3, 2026 at 10:16 AM Neelesh Salian <[email protected]> >>>>> wrote: >>>>>> >>>>>> +1 to this. Saw multiple such cases during the 1.11 release curation. >>>>>> >>>>>> On Mon, Aug 3, 2026 at 9:20 AM Kevin Liu <[email protected]> wrote: >>>>>>> >>>>>>> Hey folks, >>>>>>> >>>>>>> I’m proposing that we change the GitHub squash-merge settings to >>>>>>> populate the commit title and body from the PR’s title and description. >>>>>>> >>>>>>> The current settings may use the branch’s commit title and messages >>>>>>> instead. This can produce unhelpful squash commits—such as “Initial >>>>>>> commit”—and cause the commit history on main to differ from the PR >>>>>>> content that was reviewed. >>>>>>> >>>>>>> Using the PR title and description would provide more consistent and >>>>>>> useful commit history, regardless of how many commits a PR contains. >>>>>>> >>>>>>> More details: https://github.com/apache/iceberg/issues/17467 >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Thanks, >>>>>>> Kevin
