<div dir="ltr"><div dir="ltr">On Mon, Apr 18, 2022 at 8:30 AM Jonathan Bedard via webkit-dev <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">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.</div></blockquote><div><br></div><div>Isn't this something that can be easily resolved with a merge script?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">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.</div></blockquote><div><br></div><div>It seems like we can just automate this by introducing a change log rotating bot, which has the same privilege as commit queue.</div><div><br></div><div>So these two arguments seem rather weak.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Lastly, ChangeLogs are uncommon in git based projects, so new contributors will find them difficult to manage.</div></blockquote><div><br></div><div>This might be the strongest argument in favor of deprecating change logs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>2) We need a way to comment on commit messages in review</div><div><span style="white-space:pre-wrap"> </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><span style="white-space:pre-wrap">    </span><b>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></blockquote><div><br></div><div>This needs to be a mandatory / automatic system, not opt-in. I want to comment on commit messages as a reviewer. As a patch author, I don't care whether it can be easily commented on or not.</div><div><br></div><div>But if this is a required thing, then new contributors would have to learn that this file is auto-generated or needs to be edited manually in some cases so getting rid of change logs may not necessarily reduce the cognitive load in comparison to keeping the status quo (i.e. keeping change log files).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>3) Edit commit messages while creating a change, not just when committing the change</div><div><span style="white-space:pre-wrap">    </span>The “overwrite” workflow already sort of support this idea by using amend commits instead of appending commits to an existing branch</div><div><span style="white-space:pre-wrap"> </span><b>Proposal</b>: The above “COMMIT_MESSAGE” file workflow would allow iterative building of a commit message before committing</div></div></blockquote><div><br></div><div>I absolutely despise --amend commits. It's the most annoying thing I have to do whenever I'm creating patches in a git clone.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>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></blockquote><div><br></div><div>I don't think COMMIT_MESSAGE can be opt-in for the aforementioned reasons.</div><div><br></div><div>- R. Niwa</div><div><br></div></div></div>