As we migrate WebKit from Subversion to git, I would like to migrate the project away from ChangeLogs. The reason for this is that ChangeLogs make some of the features of git hard to use, namely, cherry-picking commits between branches requires conflict resolution every time. Rotating ChangeLogs is also moderately difficult in git with locked down commit access like our project has, only repository administers would, in practice, be able to rotate ChangeLogs. Lastly, ChangeLogs are uncommon in git based projects, so new contributors will find them difficult to manage. Currently, our git tooling makes very little effort to either support ChangeLogs or to provide alternatives. I have listed bellow some of the reasons I understand folks to like ChangeLogs along with possible git-based solutions, if necessary. 1) Subversion commit messages are stored server side, local development needs a copy git doesn’t have this problem. We have a local record of commit messages in every checkout. 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 3) Edit commit messages while creating a change, not just when committing the change The “overwrite” workflow already sort of support this idea by using amend commits instead of appending commits to an existing branch Proposal: The above “COMMIT_MESSAGE” file workflow would allow iterative building of a commit message before committing 4) Using git commands to view commit messages is hard There don’t seem to be many projects which have a solution for this. In practice, it seems that reducing the scope of messages shown by restricting history to a specific directory or even file is one solution, another is shorter commit messages 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. I like the COMMIT_MESSAGE and hooks proposals because they are opt-in. Contributors who wish to use native git tooling to contribute and interact with the project do not have to use either tool, but the tools are compatible enough with native git workflows that contributors who find editing and viewing commit messages primarily in a text editor Looking forward to the discussion, Jonathan Bedard WebKit Continuous Integration