Importantly, it's also longer than the 70 characters at which GitHub splits the message into a summary and description when opening a pull request on a sync branch. I've been manually un-splitting such messages when opening those pull requests, and that's getting tedious. So this change shortens the message such that GitHub won't do that anymore.
Note: I had two options for shortening the message: shorten the explanatory verbiage or truncate the revision ID. I chose the former, which makes the verbiage more opaque. I could have passed --short to git rev-parse instead, but an unambiguous revision ID today might become ambiguous tomorrow, and these commit messages are long-lived, so I thought it better to avoid that risk.
The script that syncs from upstream SpiderMonkey generates a commit message that is 92 characters long, which is longer than the 50 characters required by Node.js https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#commit-message-guidelines and the 70-75 characters required by the Linux kernel https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=HEAD.
Importantly, it's also longer than the 70 characters at which GitHub splits the message into a summary and description when opening a pull request on a sync branch. I've been manually un-splitting such messages when opening those pull requests, and that's getting tedious. So this change shortens the message such that GitHub won't do that anymore.
Note: I had two options for shortening the message: shorten the explanatory verbiage or truncate the revision ID. I chose the former, which makes the verbiage more opaque. I could have passed --short to
git rev-parseinstead, but an unambiguous revision ID today might become ambiguous tomorrow, and these commit messages are long-lived, so I thought it better to avoid that risk.