[webkit-dev] Embedding Identifiers in Commit Messages

Jonathan Bedard jbedard at apple.com
Wed Nov 11 08:59:30 PST 2020


Forgot to update this thread: taking a different approach, will be tracked by the same bug. Will answer inline.

> On Nov 11, 2020, at 7:56 AM, Michael Catanzaro <mcatanzaro at gnome.org> wrote:
> 
> On Wed, Nov 4, 2020 at 11:51 am, Jonathan Bedard <jbedard at apple.com> wrote:
>> We don´t have post commit hooks in SVN to do this sort of thing, and I don´t intend to add them now. We are going to have a system on GitHub to do this (not post commit hooks, but I won´t dive into the details here).
>> There really aren´t a lot of people who land changes outside of webkit-patch, among things that would break if folks were regularly not using webkit-patch is trac.webkit.org, which relies on the commit message being set.
> 
> Probably not often on trunk. But on stable branches, I assume 100% of changes are landed without webkit-patch? At least, I always used 'git svn dcommit' on stable branches. I also used this on trunk when I needed to fix an error in a ChangeLog (something webkit-patch is not good at doing).

Turns out, directly using svn commit (or git svn dcommit) was far more common than I originally thought. We can edit SVN changelogs after a change has landed, that’s what I’m intending on doing.

> 
>> Lastly, this doesn´t add a race-condition that wasn´t already there. One of the downsides of SVN is that, unlike git, it is a centralized version control system, so clients must be synced to upstream before committing. This is true now, even if you haven´t noticed it. If we didn´t have this race condition, our changeling history would be full of weird conflicts.
> 
> There should be no race condition because our GitHub repo should only allow fast-forward commits. A server hook can ensure the commit identifiers are sequential. Right?
> 
> 

Server hooks on GitHub are a bit difficult because GitHub (understandably) doesn’t let you run arbitrary code inside a commit action. Most projects handle this by having a merge-queue that runs code prior to landing a change (which is what we’re intending on doing).


More information about the webkit-dev mailing list