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 <mailto: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 <mailto: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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev