<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">1) Subversion commit messages are stored server side, local development needs a copy</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>git doesn’t have this problem. We have a local record of commit messages in every checkout.</div><div class="">2) We need a way to comment on commit messages in review</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">Proposal</b>: Tooling should support a “COMMIT_MESSAGE” file in each pull request commit that becomes COMMIT_MESSAGE when a pull request is landed</div><div class="">3) Edit commit messages while creating a change, not just when committing the change</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>The “overwrite” workflow already sort of support this idea by using amend commits instead of appending commits to an existing branch</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">Proposal</b>: The above “COMMIT_MESSAGE” file workflow would allow iterative building of a commit message before committing</div><div class="">4) Using git commands to view commit messages is hard</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">Proposal</b>: 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.</div><div class=""><br class=""></div><div class="">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</div><div class=""><br class=""></div><div class="">Looking forward to the discussion,</div><div class=""><br class=""></div><div class="">Jonathan Bedard</div><div class="">WebKit Continuous Integration</div></body></html>