> It seems to me that you can write a script that just applies a patch while > ignoring changes to each change log file, then separately prepend each > change log entry. I don't see why such a script would behave differently > for reverting multiple commits or rebasing a feature onto a branch. In > those cases where codebase has enough divergence, merge conflicts are > probably more of an issue with the codebase itself, and not change log > entries.
There are many types of changes which are not compatible with patches. “Write a change which applies a patch” is not a general solution. It wasn’t a general solution in Subversion, and it’s not a general solution in git. Speaking as the person who has to maintain our patch workflows, there are many edge cases to patch workflows that tend to bite you with precisely the kind of large changes which are difficult to manually sift through. Patch workflows also represent a huge risk for Apple’s software update branches where changes are cherry-picked by engineers who aren’t familiar with the technical details of the changes their cherry-picking. These workflows have already been using git for years at this point because patches do not work reliably for this type of work. > .. or robust solution. Bots need maintenance and intervention, and a bot with > commit access has another set of issues. Repository admins occasionally > rotating ChangeLogs is going to be less expensive than a bot doing it. > > Either way, it doesn't seem like this is a higher cost issue compared to > all WebKit contributors having to change their workflows. We are moving to git. Workflows _are_ changing. I’m interested in making sure the workflows can achieve the same things the old ones did, not in preserving the old workflows. > > folks familiar with git won?t realize what has happened until they see > their PR diff), ?mandatory? is a bit tougher because we can?t prevent folks > from filing a pull request without using tooling. At that point, we?re > where we are today with PR template that encourages tool usage, explains > how to craft a PR the ways tools do it and then reviewers acting as a > gate-keeper. The last point is more about project policy than it is tooling. > > We should automatically reject such PR requests. We should not automatically reject PRs made in good faith. One of the reasons we’re moving to GitHub is to make the project more approachable for new contributors. Having a machine rejects PRs because a contributor is not familiar with project norms goes against this goal. > … judgments about personal preferences for local development. From my > discussions with folks, it seems that the project is pretty evenly split on > --amend commits, with some contributors preferring them and others > preferring to make multiple commits. My purpose in bringing up --amend > commits is that one of the things I?ve heard folks find useful about > ChangeLogs is the ability to iteratively build them, which is something > that does have a parallel in raw git workflows. > > No, my option isn't between amending a commit vs. making multiple commits. > I really don't like making *any local commits* at all. I want to work on a > patch without ever making local commits, and upload whatever change I may > have relative to the main branch's HEAD is. Our tooling supports and will continue to support workflows where the tooling automatically makes commits for you. Discussions of other workflows is important because we don’t want to build extra tooling for the project if there is already a native git workflow which address a specific concern.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
