[webkit-dev] Embedding Identifiers in Commit Messages

[Jonathan Bedard]

>> On Mon, Nov 2, 2020 at 2:04 PM Jonathan Bedard <jbedard at apple.com <https://lists.webkit.org/mailman/listinfo/webkit-dev>> wrote:
>> 
>>> We appreciate everyone’s feedback on transitioning away from Subversion to Git, I’ll be releasing
>>> an expected timeline of up-coming changes in the next week before the contributors meeting.
>>> 
>>> In the mean time, we’re preparing on adding identifiers to new commit messages, that work is
>>> tracked in https://bugs.webkit.org/show_bug.cgi?id=218407. <https://bugs.webkit.org/show_bug.cgi?id=218407.> At the moment, we’re likely going to be
>>> appending the identifiers to commit messages (as the current change proposes), but I wanted to
>>> provide a chance for folks to object to this change before it becomes canonical.
>> 
>> I'm a bit confused here. It looks like the patch only affects commits
>> made via webkit-patch. Given there are a lot of people who don't use
>> webkit-patch land, I'm not certain this strategy is sound even in the
>> short term. Why don't we do this in post commit hook instead?

> Yes, if your reason for switching to Git is making things easy for people using Git to contribute,
> please try to use the standard Git commands as much as possible. Otherwise, from a developer experience
> point of view you are still doing your custom system, and it does not matter that the backend is Git.

> You can use an approach similar to the hook used for Gerrit:
> https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html <https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html>

> Note that this hook runs locally on developer's machine, but you can additionally have a server-side hook that
> checks that the id is indeed present in the commit message, and rejects the commit otherwise (Gerrit also does
> this for its Change-Id). I think it is not possible to alter the commit message from server-side with a standard
> Git server, it would create confusion because the local branch from the developer machine would not match what's
> on the server.

> -- 
> Adrien.
The long term plan is to have the default branch be protected and all commits go though commit-queue. This means that contributors are using the default set of git commands, but most contributors (even committers and reviewers) would not have push access to the default branch (and other “production” branches, although we need to define exactly what that means), and are instead sending pull requests to commit-queue (or merge-queue, if you prefer, it may be re-branded) to be landed.

The mechanics of the current change operate on SVN, not Git. And we already rely pretty heavily on contributors using webkit-patch to land changes, trac.webkit.org <http://trac.webkit.org/> wouldn’t work well if the vast majority of contributors were not using it to land change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201104/59390e2d/attachment.htm>