[webkit-dev] ChangeLog Deprecation Plans

[Yusuke Suzuki]

> On Apr 18, 2022, at 12:51 PM, Michael Catanzaro via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> On Mon, Apr 18 2022 at 08:30:04 AM -0700, Jonathan Bedard via webkit-dev <webkit-dev at lists.webkit.org> wrote:
>> 2) We need a way to comment on commit messages in review
>> 	Current tooling sets the pull request description as the commit message, “Quote Reply” kind of provides a way to inline comment, although it´s not the formal review UI
>> 	Proposal: Tooling should support a “COMMIT_MESSAGE” file in each pull request commit that becomes COMMIT_MESSAGE when a pull request is landed
> 
> Although it's inconvenient that we won't be able to leave inline comments on commit messages anymore, is that really so serious a loss that it requires a strange workaround? It just doesn't seem like a very big deal? We can copy and paste and quote when we suggest changes in commit messages.

I think this is important. We are using commit message / ChangeLog as a document tied to the change, and we are writing very detailed description to make the intention / design of the change clear and making it as a good document when we read the change via git-blame, bisect, using that header, investigating how it works etc.
To make / keep this commit message / ChangeLog helpful, we need review, and I think reviewing of these messages is critical to keep usefulness of them.

I think COMMIT_MESSAGE proposal has various good benefits.

1. We can review commit mesasges.
2. In local development, we can commit expected COMMIT_MESSAGE file directly in our tree. We can eventually add more and more detailed information to this file while local development continues, and we can also revert COMMIT_MESSAGE change since it can be commited in the local branch. 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.
3. This solves the problem how to squash multiple commits in one PR. Merge-queue can just look at this file and use this as a commit message when squashing and landing. This means that, in a PR, we can push multiple small commits in our PR branch. Merge-queue can get canonical COMMIT_MESSAGE when squashing, so keeping one-commit-per-one-PR in the upstream branch is easy. This allows normal git-based development workflow while keeping commit-message format canonical: creating a topic branch, committing many small changes to this branch, creating a PR, and PR gets merged into the upstream as a single commit.

-Yusuke

> 
>> 	Proposal: Have Tools/Scripts/git-webkit setup configure hooks in contributors local git repositories to lay down CommitMessages.history files on merge, checkout and commit which contain the last 5000 commit messages. We can put these in similar places to where ChangeLogs are today, although we would likely want them in fewer places because this will increase local compute time on many git operations. We could also make this a configurable setting so that engineers who are more comfortable with the raw command line tooling do not have to deal with slower git operations.
> 
> What's wrong with `git log`?
> 
> There are GUI apps that can visualize your git history if so desired, e.g. GNOME has gitg.
> 
> Michael
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220418/51ebf295/attachment.htm>