I spent some time discussing this offline with Yusuke to better understand his proposal.

It sounds like Yusuke’s proposal is:
1. Have a separate COMMIT_MESSAGE file as part of the PR
2. When the merge queue commits the PR, it uses that COMMIT_MESSAGE content as commit log message and then drops the file from the commit.

I understand that this approach is a bit more flexible for people who like to make multiple commits locally for the same PR. I personally always have a single commit per PR that I keep amending but I think it is good to be flexible.
It also makes reviewing the changelog message a bit easier on GitHub.

I support Yusuke’s proposal. It is a bit more flexible and it still means that separate full/history ChangeLog files would be a thing of the past.

--
 Chris Dumez




On Apr 22, 2022, at 2:10 PM, Chris Dumez via webkit-dev <webkit-dev@lists.webkit.org> wrote:

I am strongly in favor of dropping the ChangeLog files and relying on the GIT commit message instead. Not having to update ChangeLog files was actually a big motivator for me to switch to GitHub, as I thought until now we didn’t have to update ChangeLog files when switching Github PRs.

With the provided GIT commit hook, the changelog format is identical to what we had in the ChangeLog files anyway. I don’t understand (yet) the need for having the same message in two separate location.

Git commit logs don’t roll over (like ChangeLog files do), they are searchable, they have the same format (you CAN add inline comments on a per-file basis for e.g.). They are also easily modifiable from the GitHub interface.

I will also note that ChangeLog files are a frequent source of conflicts when using GIT. Yes, we do have a resolve-ChangeLogs script that’s supposed to help with that. However, please note that this script hasn’t work reliably for quite a while (at least for many of us at Apple with very recent SDKs).
ChangeLog entries no longer show on top when rebasing, meaning I have to move them back on top manually. Worse, if I fail to notice and use `webkit-patch upload`, it will upload to the wrong bugzilla bug.

If people really still want to maintain separate ChangeLog files, I am hoping this can be generated from my commit messages and done automatically for me upon committing. I really don’t want that as part of my patch/PR.

--
 Chris Dumez




On Apr 19, 2022, at 11:00 AM, Geoffrey Garen via webkit-dev <webkit-dev@lists.webkit.org> wrote:

Commit message is tied to a commit, so editing commit without breaking commit-message is hard (how to revert one change from one commit without rewriting commit message? It requires some git hack). Separate independent COMMIT_MESSAGE file can solve this problem and makes local development easy.

Developers who are used to git -- which nowadays is pretty much everyone except WebKit devs -- are also used to rewriting commit messages.

I think it’s important for WebKit's git transition to take consideration of WebKit developers and WebKit workflows. I hope we can agree on this premise as we discuss various options for commit messages.

Thanks,
Geoff
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev