First, get a feel for it by practicing in this repo:
# Get the presquash code:
$ git checkout post-squash
$ git log --pretty=format:"%Cgreen%h%Creset %Cblue%ad%Creset %s%C(yellow)%d%Creset %Cblue[%an]%Creset" --graph --date=short
* 666a1a7 2015-04-02 Commit 4: file is "d" (HEAD, tag: pre-squash, pre-squash) [Josh Cheek]
* c14180c 2015-04-02 Merge commit 3b into 3 [Josh Cheek]
|\
| * 603a5fb 2015-04-02 Commit 3b: file2 is "a" [Josh Cheek]
* | 067ac25 2015-04-02 Commit 3: file is "c" (master) [Josh Cheek]
|/
* 529fa86 2015-04-02 Commit 2: file is "b" [Josh Cheek]
* dfc9e7b 2015-04-02 Commit 1: file is "a" [Josh Cheek]
$ git rebase -i 529fa86
# They are in the reverse order, so should be:
# pick 067ac25 Commit 3: file is "c"
# pick 603a5fb Commit 3b: file2 is "a"
# pick 666a1a7 Commit 4: file is "d"
#
# Apparently the merge commit is omitted.
#
# Change them so that 3 comes after 3b
# pick 603a5fb Commit 3b: file2 is "a"
# pick 067ac25 Commit 3: file is "c"
# pick 666a1a7 Commit 4: file is "d"
#
# Mark commit 4 to be squashed into commit 3 (the one above it)
# pick 603a5fb Commit 3b: file2 is "a"
# pick 067ac25 Commit 3: file is "c"
# squash 666a1a7 Commit 4: file is "d"
#
# Save and quit, this will reopen the editor with both messages
# Write the new message, save and quitHow I did this for my RSpec commit.
I actually have this command aliased to gh,
but expanding it so you don't have to have my dotfiles
to make sense of what I did.
$ git log --pretty=format:"%Cgreen%h%Creset %Cblue%ad%Creset %s%C(yellow)%d%Creset %Cblue[%an]%Creset" --graph --date=short
* 2f50d20 2015-03-28 Tweaking code to make robots happy (HEAD, josh/threadsafe-let-block-unsquashed, josh/threadsafe-let-block, updated-benchmarks-for-pr-1858) [Josh Cheek]
* 201ec34 2015-03-28 Add documentation for threadsafe configuration value (josh) [Josh Cheek]
* 2daae80 2015-03-28 Alternate benchmark implementation [Josh Cheek]
* 1ee7a8d 2015-03-28 Update threadsafe benchmarks [Josh Cheek]
* 048643b 2015-03-28 Set memoized helpers to be threadsafe or not based on RSPec.configuration.threadsafe? [Josh Cheek]
* 5bde9b9 2015-03-28 Threadsafety can be configured (defaults to true) [Josh Cheek]
* dd193ed 2015-03-28 Parse --[no-]threadsafe [Josh Cheek]
* e5e4076 2015-03-26 Add some comments explaining strange code. [Josh Cheek]
* a8cdc04 2015-03-23 Memoization object is instantiated prior to first access [Josh Cheek]
* e8c1ee4 2015-03-23 Shorten comment [Josh Cheek]
* c8b1f27 2015-03-22 Merge commit '9f01d6ff188483805d9cdd8758889a2e612a1a1e' into updated-benchmarks-for-pr-1858 [Josh Cheek]
* cd457f4 2015-03-15 Small refactorings on threadsafe specs [Josh Cheek]
* 8c0f022 2015-03-15 Bump dependency on thread_order to 1.1.0 [Josh Cheek]
* e32ada9 2015-03-14 Tell SimpleCov to ignore 1.8.7 only code [Josh Cheek]
* a0179d2 2015-03-14 Update name for 1.8.7 [Josh Cheek]
* 3b5960b 2015-03-14 Appease Rubocop, the pedant [Josh Cheek]
* 3c3cef4 2015-03-14 Fix for CI [Josh Cheek]
* cc0bdb2 2015-03-14 Memoization pays for thread synchronization only on first access [Josh Cheek]
* 47ab55f 2015-03-14 Remove unnecessary spec that fails [Josh Cheek]
* 8e1b64e 2015-03-14 Extract thread_order_support helper into thread_order gem [Josh Cheek]
* 20edd76 2015-03-08 Replace big long comment with link to the explanation [Josh Cheek]
* 1ed82db 2015-02-24 Compare keys as Strings instead of Symbols, b/c used to not have Symbol#<=> [Josh Cheek]
* 1d1d67b 2015-02-24 Fix failures on CI [Josh Cheek]
* 333b813 2015-02-23 Mark ReentrantMutex private [Josh Cheek]
* 2bdc8d0 2015-02-23 Merge upstream branch, update benchmarks (josh/updated-benchmarks-for-pr-1858, threadsafe-let-block) [Josh Cheek]
|\
| * bb1ee74 2015-02-07 Fix failures for older Rubies [Josh Cheek]
| * 00d9b1d 2015-02-07 Add benchmarks for threadsafe let block [Josh Cheek]
| * 9daea33 2015-02-01 Make memoized helpers threadsafe [Josh Cheek]
* 1dc69cd 2015-02-23 ThreadOrderSupport Filename follows conventional naming schemes [Josh Cheek]
* 52062d2 2015-02-23 Implement ReentrantMutex [Josh Cheek]
* 6bc1025 2015-02-23 Move stdlib thread access into ReentrantMutex [Josh Cheek]
* 504842e 2015-02-23 MemoizedHelpers can call super [Josh Cheek]
* 3f7989e 2015-02-23 Refactor MemoizedHelpers threadsafe tests [Josh Cheek]
* 59bdde7 2015-02-23 Memoized threadsafty implemented with Monitor [Josh Cheek]
* 4abce54 2015-02-22 ThreadOrderSupport does almost all its work through the queue [Josh Cheek]
* 1363de6 2015-02-17 Switch ThreadOrderSupport interface [Josh Cheek]
* 520eb15 2015-02-14 Implement suggestions from PR [Josh Cheek]
* d07be2d 2015-02-07 Fix failures for older Rubies [Josh Cheek]
* fffdde7 2015-02-07 Add benchmarks for threadsafe let block [Josh Cheek]
* 8ad60ee 2015-02-01 Make memoized helpers threadsafe [Josh Cheek]
* de29068 2011-12-02 Add colour option for -p's slow test output (josh/profile-color-customization) [Josh Cheek]
@cdemyanovich and I made a commit to RSpec back in 2011, which isn't part of this, so omit it, and go with the current one.
NOTE This was apparently wrong, I think I needed to do the parent of this commit. I wind up having to fix it at the end.
$ git rebase -i 8ad60eeThis dropped me into vim with the following contents:
pick fffdde7 Add benchmarks for threadsafe let block
pick d07be2d Fix failures for older Rubies
pick d371e84 Update thread safe `let` benchmarks.
pick 11ee951 Whoops, left the times arg, which was skewing the results.
pick 520eb15 Implement suggestions from PR
pick 1363de6 Switch ThreadOrderSupport interface
pick 4abce54 ThreadOrderSupport does almost all its work through the queue
pick 59bdde7 Memoized threadsafty implemented with Monitor
pick 3f7989e Refactor MemoizedHelpers threadsafe tests
pick 504842e MemoizedHelpers can call super
pick 6bc1025 Move stdlib thread access into ReentrantMutex
pick 52062d2 Implement ReentrantMutex
pick 1dc69cd ThreadOrderSupport Filename follows conventional naming schemes
pick 9daea33 Make memoized helpers threadsafe
pick 00d9b1d Add benchmarks for threadsafe let block
pick bb1ee74 Fix failures for older Rubies
pick 333b813 Mark ReentrantMutex private
pick 1d1d67b Fix failures on CI
pick 1ed82db Compare keys as Strings instead of Symbols, b/c used to not have Symbol#<=>
pick 20edd76 Replace big long comment with link to the explanation
pick 8e1b64e Extract thread_order_support helper into thread_order gem
pick 47ab55f Remove unnecessary spec that fails
pick cc0bdb2 Memoization pays for thread synchronization only on first access
pick 3c3cef4 Fix for CI
pick 3b5960b Appease Rubocop, the pedant
pick a0179d2 Update name for 1.8.7
pick e32ada9 Tell SimpleCov to ignore 1.8.7 only code
pick 8c0f022 Bump dependency on thread_order to 1.1.0
pick cd457f4 Small refactorings on threadsafe specs
pick 9f01d6f Update thread safe let benchmark.
pick e8c1ee4 Shorten comment
pick a8cdc04 Memoization object is instantiated prior to first access
pick e5e4076 Add some comments explaining strange code.
pick dd193ed Parse --[no-]threadsafe
pick 5bde9b9 Threadsafety can be configured (defaults to true)
pick 048643b Set memoized helpers to be threadsafe or not based on RSPec.configuration.threadsafe?
pick 1ee7a8d Update threadsafe benchmarks
pick 2daae80 Alternate benchmark implementation
pick 201ec34 Add documentation for threadsafe configuration value
pick 2f50d20 Tweaking code to make robots happy
# Rebase 8ad60ee..2f50d20 onto 8ad60ee
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
They were all mine (which I don't totally understand, b/c at some point I know I merged master into it). The only exceptions were @myronmarston's commits to the benchmark.
The first commit was out of order, not really sure why, maybe because it was a parent of one of Myron's commits.
Regardless, it seemed fine to squash them all.
I updated the file to look like this, then saved and quit:
pick fffdde7 Add benchmarks for threadsafe let block
s d07be2d Fix failures for older Rubies
s d371e84 Update thread safe `let` benchmarks.
s 11ee951 Whoops, left the times arg, which was skewing the results.
s 520eb15 Implement suggestions from PR
s 1363de6 Switch ThreadOrderSupport interface
s 4abce54 ThreadOrderSupport does almost all its work through the queue
s 59bdde7 Memoized threadsafty implemented with Monitor
s 3f7989e Refactor MemoizedHelpers threadsafe tests
s 504842e MemoizedHelpers can call super
s 6bc1025 Move stdlib thread access into ReentrantMutex
s 52062d2 Implement ReentrantMutex
s 1dc69cd ThreadOrderSupport Filename follows conventional naming schemes
s 9daea33 Make memoized helpers threadsafe
s 00d9b1d Add benchmarks for threadsafe let block
s bb1ee74 Fix failures for older Rubies
s 333b813 Mark ReentrantMutex private
s 1d1d67b Fix failures on CI
s 1ed82db Compare keys as Strings instead of Symbols, b/c used to not have Symbol#<=>
s 20edd76 Replace big long comment with link to the explanation
s 8e1b64e Extract thread_order_support helper into thread_order gem
s 47ab55f Remove unnecessary spec that fails
s cc0bdb2 Memoization pays for thread synchronization only on first access
s 3c3cef4 Fix for CI
s 3b5960b Appease Rubocop, the pedant
s a0179d2 Update name for 1.8.7
s e32ada9 Tell SimpleCov to ignore 1.8.7 only code
s 8c0f022 Bump dependency on thread_order to 1.1.0
s cd457f4 Small refactorings on threadsafe specs
s 9f01d6f Update thread safe let benchmark.
s e8c1ee4 Shorten comment
s a8cdc04 Memoization object is instantiated prior to first access
s e5e4076 Add some comments explaining strange code.
s dd193ed Parse --[no-]threadsafe
s 5bde9b9 Threadsafety can be configured (defaults to true)
s 048643b Set memoized helpers to be threadsafe or not based on RSPec.configuration.threadsafe?
s 1ee7a8d Update threadsafe benchmarks
s 2daae80 Alternate benchmark implementation
s 201ec34 Add documentation for threadsafe configuration value
s 2f50d20 Tweaking code to make robots happy
I had a conflict, b/c when I saved and quit, it said this:
$ git rebase -i 8ad60ee
error: could not apply 9daea33... Make memoized helpers threadsafe
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply 9daea3316b07736ac536f104d443d2f29e7ed722... Make memoized helpers threadsafe
The issue was in lib/rspec/core/memoized_helpers.rb
$ git status
rebase in progress; onto 8ad60ee
You are currently rebasing branch 'updated-benchmarks-for-pr-1858' on '8ad60ee'.
(fix conflicts and then run "git rebase --continue")
(use "git rebase --skip" to skip this patch)
(use "git rebase --abort" to check out the original branch)
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: spec/rspec/core/memoized_helpers_spec.rb
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: lib/rspec/core/memoized_helpers.rb
Two commits had changed the name of the memoized method.
One to fetch_or_store, the other to for.
This showed up in several places, but approximately looked like:
<<<<<<< HEAD
__memoized.fetch_or_store(:subject) do
described = described_class || self.class.metadata.fetch(:description_args).first
Class === described ? described.new : described
||||||| parent of 9daea33... Make memoized helpers threadsafe
__memoized.fetch(:subject) do
__memoized[:subject] = begin
described = described_class || self.class.metadata.fetch(:description_args).first
Class === described ? described.new : described
end
=======
__memoized.for(:subject) do
described = described_class || self.class.metadata.fetch(:description_args).first
Class === described ? described.new : described
>>>>>>> 9daea33... Make memoized helpers threadsafeI chose fetch_or_store, because that's what was in the final commit.
Double checked before continuing, and I'd fucked it up, deleted a line that should stay:
$ git diff
diff --cc lib/rspec/core/memoized_helpers.rb
index 8390800,01f74aa..0000000
--- a/lib/rspec/core/memoized_helpers.rb
+++ b/lib/rspec/core/memoized_helpers.rb
@@@ -55,9 -53,9 +55,8 @@@ module RSpe
# @see #should_not
# @see #is_expected
def subject
- __memoized.for(:subject) do
+ __memoized.fetch_or_store(:subject) do
described = described_class || self.class.metadata.fetch(:description_args).first
-- Class === described ? described.new : described
end
end
So went back and fixed that
$ git diff
diff --cc lib/rspec/core/memoized_helpers.rb
index 8390800,01f74aa..0000000
--- a/lib/rspec/core/memoized_helpers.rb
+++ b/lib/rspec/core/memoized_helpers.rb
Franky, I have no idea what that means, but add it, I guess.
$ git add lib
Now that the conflict is resolved, continue with the commit.
$ git rebase --continue
At this point it dropped me into an editor again, with 14 commit messages, like before. From experience, I know it considers leading pound signs to be comments, so I switched them all to stick around, figuring I'll first get the commits right, then come back and figure out what I want to say. So, edited them to look like this:
This is a combination of 14 commits.
The first commit's message is:
==============================
Add benchmarks for threadsafe let block
As requested in https://github.com/rspec/rspec-core/pull/1858
This is the 2nd commit message:
===============================
Fix failures for older Rubies
# ...
When I quit the editor, it then continued on with the rebase (how the fuck am I conflicting with myself?! -.0)
$ git rebase --continue
[detached HEAD ff3264e] This is a combination of 14 commits.
Date: Sat Feb 7 00:56:57 2015 -0700
7 files changed, 629 insertions(+), 19 deletions(-)
create mode 100644 benchmarks/threadsafe_let_block.rb
create mode 100644 lib/rspec/core/reentrant_mutex.rb
create mode 100644 spec/rspec/core/reentrant_mutex_spec.rb
create mode 100644 spec/support/thread_order_support.rb
create mode 100644 spec/support_specs/thread_order_spec.rb
error: could not apply 00d9b1d... Add benchmarks for threadsafe let block
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply 00d9b1dad61a441a32b15b24abd362e1a0cda2e0... Add benchmarks for threadsafe let block
Same process as before. This time, conflict is in benchmarks/threadsafe_let_bloc.rb
Conflict was the entire file. I decided to again go with the one from HEAD.
I have no idea which is right, b/c it's really unclear what the parents are.
The one I can see, 00d9b1d, but the other is just "HEAD", which I assume is the
current status of the squashing.
Figure I'll check them at the end and just overwrite the file with the final result, if its still wrong.
As an aside, I need to start including the date in output like this.
Doesn't seem like it should be this hard :/ Maybe I needed to put them into a smarter order, perhaps the commits in the file were based on commit date or something.
Or maybe I should not have gone with HEAD, and chosen for over fetch_or_store.
I don't really understand the implications of such a decision.
$ git rebase --continue
error: could not apply bb1ee74... Fix failures for older Rubies
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply bb1ee74b94f8ef7c21862e2808d85717ad6a64a0... Fix failures for older Rubies
$ git status
rebase in progress; onto 8ad60ee
You are currently rebasing branch 'updated-benchmarks-for-pr-1858' on '8ad60ee'.
(fix conflicts and then run "git rebase --continue")
(use "git rebase --skip" to skip this patch)
(use "git rebase --abort" to check out the original branch)
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: lib/rspec/core/memoized_helpers.rb
$ gd lib
diff --cc lib/rspec/core/memoized_helpers.rb
index 8390800,3848810..0000000
--- a/lib/rspec/core/memoized_helpers.rb
+++ b/lib/rspec/core/memoized_helpers.rb
@@@ -1,5 -1,5 +1,11 @@@
++<<<<<<< HEAD
+require 'rspec/core/reentrant_mutex'
126 @__memoized ||= Memoized.new
+
++||||||| parent of bb1ee74... Fix failures for older Rubies
++=======
+ require 'thread'
+
++>>>>>>> bb1ee74... Fix failures for older Rubies
module RSpec
module Core
# This module is included in {ExampleGroup}, making the methods
@@@ -130,12 -130,24 +136,26 @@@
class Memoized
def initialize
@memoized = {}
- @mutex = Mutex.new
+ @mutex = ReentrantMutex.new
end
++<<<<<<< HEAD
+ def fetch_or_store(key)
++||||||| parent of bb1ee74... Fix failures for older Rubies
++ def for(key, &initializer)
++ return @memoized[key][0] if @memoized.has_key? key
++
++ value = initializer.call
++
++=======
+ def for(key, &initializer)
+ return @memoized[key][0] if @memoized.key? key
+
+ value = initializer.call
+
++>>>>>>> bb1ee74... Fix failures for older Rubies
@mutex.synchronize do
- memoized = (@memoized[key] ||= [value, Thread.current.object_id])
- if memoized[1] == Thread.current.object_id
- # set by call to super in initializer, we override. ie:
- # let(:title) { super() + ' Child Context' }
- memoized[0] = value
- else
- # some other thread beat us to it, stick with their value
- memoized[0]
- end
+ @memoized.fetch(key) { @memoized[key] = yield }
end
end
end
Fix it, get another conflict, this time in the benchmarks. Fix that, too
After fixing that one, it puts me into another commit message, the first one is mine from the earlier squash.
This time it's 8 commits. I'm not really sure how it decides when to make these breaks. The 14 from before make sense, there were 14 commits up to the merge commit. This one, I'm not really sure.
I decide to just indent the recent ones and put off the messages even longer.
It now looks like this:
This is a combination of 8 commits.
The first commit's message is:
==============================
This is a combination of 14 commits.
The first commit's message is:
==============================
Add benchmarks for threadsafe let block
As requested in https://github.com/rspec/rspec-core/pull/1858
This is the 2nd commit message:
===============================
Fix failures for older Rubies
# ...
This is the 2nd commit message:
==============================
Mark ReentrantMutex private
In part b/c it's probably volatile,
In parat b/c it's breaking on CI due since #synchronize isn't documented.
# ...
Another merge conflict in benchmarks. This time I at least have some decent shas,
but it's just in the recorded timings and such, which are all going to go away,
so I decided to just delete the whole section after the __END__. That worked out
rather nicely, actually, it got me to the next "aggregated chunk".
I came up with a nice vim macro to automate what I'd been doing. Saved committed.
Another conflict in benchmarks. I expected this, though, my last resolution was pretty bs. But it was a good choice, because now it was trivially easy to resolve the conflict. The one I'd deleted had no content, the one in conflict had only one single conflict, which was its entire contents. So I just went with that. It was the only conflict in this batch.
The last one had no conflicts. Amusingly the commit message starts with:
This is a combination of 4 commits.
The first commit's message is:
==============================
This is a combination of 8 commits.
The first commit's message is:
==============================
This is a combination of 8 commits.
The first commit's message is:
==============================
This is a combination of 8 commits.
The first commit's message is:
==============================
This is a combination of 14 commits.
The first commit's message is:
==============================
$ git show 2f50d20:benchmarks/threadsafe_let_block.rb > expected_benchmarks.rb
$ diff expected_benchmarks.rb benchmarks/threadsafe_let_block.rbUhhh... nope, the output was from the wrong run. Decided to just trash what the rebase came up with and replace it with the expected result.
$ mv expected_benchmarks.rb benchmarks/threadsafe_let_block.rb
$ git add benchmarks
$ git commit --amend -CHEAD
[updated-benchmarks-for-pr-1858 b0e656b] This is a combination of 4 commits.
Date: Sat Feb 7 00:56:57 2015 -0700
12 files changed, 707 insertions(+), 31 deletions(-)
create mode 100644 benchmarks/threadsafe_let_block.rb
create mode 100644 lib/rspec/core/reentrant_mutex.rb
create mode 100644 spec/rspec/core/reentrant_mutex_spec.rbsigh How did it go so smoothly in my prep example? Fkn do it again:
$ git rebase 'HEAD^^'
# ...
$ gh -10
* 9fae44a 2015-02-01 This is a combination of 2 commits. (HEAD, updated-benchmarks-for-pr-1858) [Josh Cheek]
* 9d12a30 2015-02-06 Merge pull request #1866 from rspec/expose_reporter_and_allow_message [Jon Rowe]
|\
| * 2633182 2015-02-05 switch NullReporter to not be an instance [Jon Rowe]
| * 41e8447 2015-02-05 changelog for #1866 [skip ci] [Jon Rowe]
| * 44b36c7 2015-02-05 make Reporter#message a public api [Jon Rowe]
| * 038a183 2015-02-05 expose the reporter from a running example [Jon Rowe]
* | 703e742 2015-02-05 Merge pull request #1865 from rsanchez79/specForWindows [Jon Rowe]
- Is the reentrant mutex file there? (yes)
- There aren't any diffs leftover? (correct)
- The final result has
fetch_or_store, notfor? (correct) - All tests are passing? (yes)
- Rubocop is chill? (yes -- took me forever to realize I could get it to tell me locally)
- Cukes pass? (idk, can't figure out which incantation I came up with to run the things. Keeps saying
invalid option: --threadsafe, which means its finding rspec/core from the environment instead of the library code) - Benchmarks run and have approximately similar results? (yes)
Okay... time for a cigarette, I'll come deal with the message later.
Was actually not that hard, just took a bit of focus for an hour or so. Shoulda gotten to it sooner, just been feelin a little off lately.
Huh. I gave the diff a last once-over before submitting it, and found that it had added a test that I'd removed. I assume it didn't come up in conflicts, or I would have seen it. But looking at it, though, even on the unsquashed branch, I couldn't really tell where I'd removed it :/ I think that history must have gotten changed at some point, and just made things wonky.
Tried tweaking a few things (the public/private attribute in MemoizedHelpers)
after squashing, and then did git commit --amend -CHEAD
to add them to the big commit. But later, ran the suite and saw that there
were tests that would fail as a consequence (behaviour was still the same,
something was using reflection to assert how many nonprivate methods there were)
But since I'd amended the commit, I couldn't checkout to the previous state.
Fortunately, git reflog had both commits in it, and I was able to get a diff
of them by pasting the shas into git diff <SHA1> <SHA2>, and then swapped
their order to get the undo diff. In general, you can do this, then, to fix it.
git diff --patch 'HEAD@{0}' 'HEAD@{1}' | git apply -That's kinda wonderful, if you ask me!
This went uncomfortably smooth...
$ git remote update
$ git rebase origin/master
No issues. I then double checked shas and such, to make sure I had really done it. They were all good. Did another once-over on the diff, it was fine. Ran the specs, they passed. Ran Rubocop, all was well.
So, I think it's ready.
$ git push --force josh threadsafe-let-block:threadsafe-let-block
Looks like it worked!