Stream: git-wasmtime

Topic: wasmtime / PR #11815 Merge a non-functional Wizer into Wa...

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:18):

alexcrichton opened PR #11815 from alexcrichton:wizer-inert to bytecodealliance:main:

This is a history-preserving version of https://github.com/bytecodealliance/wasmtime/pull/11805 without any Wasmtime-specific changes. The goal here is to merge everything into this repo while only worrying about preserving the history and then a follow-up PR would actually integrate Wizer with Wasmtime.

This history was procedurally created with by running these commands in a Wizer clone:

python3 ~/git-filter-repo --to-subdirectory-filter crates/wizer
python3 ~/git-filter-repo --invert-paths --path crates/wizer/benches/uap_bench.wizer.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/benches/regex_bench.wizer.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/benches/uap_bench.control.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/benches/regex_bench.control.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/tests/regex_test.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/.github/actions/github-release
git push git@github.com:alexcrichton/wizer main:wasmtime-merge -f
```

and then running these commands in Wasmtime

```
git fetch https://github.com/alexcrichton/wizer wasmtime-merge
git merge FETCH_HEAD --allow-unrelated-histories
```

Notably the big binary blobs are removed from the history to avoid pulling in too much new size here (`uap_bench.wizer.wasm` was 35M+).

A final commit is then handwritten which excludes `crates/wizer` from the overall workspace and that's intended to be the starting point to rebase #11805 onto after merging.

Procedurally I do not plan to use the merge queue for this PR. Instead I plan on waiting for CI to fully pass on this PR and then I'll push this directly to `main` after toggling a switch in the settings for "allow admins to bypass restrictions". I'll then re-enable that switch after I do the push.
~~~

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:18):

alexcrichton requested dicej for a review on PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:18):

alexcrichton requested wasmtime-core-reviewers for a review on PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:18):

alexcrichton requested wasmtime-default-reviewers for a review on PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:19):

alexcrichton updated PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:20):

alexcrichton updated PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:21):

alexcrichton updated PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:22):

dicej submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:22):

alexcrichton edited PR #11815:

This is a history-preserving version of https://github.com/bytecodealliance/wasmtime/pull/11805 without any Wasmtime-specific changes. The goal here is to merge everything into this repo while only worrying about preserving the history and then a follow-up PR would actually integrate Wizer with Wasmtime.

This history was procedurally created with by running these commands in a Wizer clone:

python3 ~/git-filter-repo --to-subdirectory-filter crates/wizer
python3 ~/git-filter-repo --invert-paths --path crates/wizer/benches/uap_bench.wizer.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/benches/regex_bench.wizer.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/benches/uap_bench.control.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/benches/regex_bench.control.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/tests/regex_test.wasm
python3 ~/git-filter-repo --invert-paths --path crates/wizer/.github/actions/github-release
git push git@github.com:alexcrichton/wizer main:wasmtime-merge -f

and then running these commands in Wasmtime

git fetch https://github.com/alexcrichton/wizer wasmtime-merge
git merge FETCH_HEAD --allow-unrelated-histories

Notably the big binary blobs are removed from the history to avoid pulling in too much new size here (uap_bench.wizer.wasm was 35M+).

A final commit is then handwritten which excludes crates/wizer from the overall workspace and that's intended to be the starting point to rebase #11805 onto after merging.

Procedurally I do not plan to use the merge queue for this PR. Instead I plan on waiting for CI to fully pass on this PR and then I'll push this directly to main after toggling a switch in the settings for "allow admins to bypass restrictions". I'll then re-enable that switch after I do the push.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 15:25):

alexcrichton updated PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 16:01):

alexcrichton updated PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 16:09):

alexcrichton updated PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 20:41):

cfallin commented on PR #11815:

Procedural idea: to keep history linear and thus make Wasmtime bisects less confusing, would it make sense to graft the initial commit of Wizer on top of Wasmtime main? Then the history goes from

(wizer initial) ------------------\
                                   >--(merge)----------
(Wasmtime initial)----------------/

to

                                               /--(wizer initial) ------------------\
                                              /                                      >--(merge)----------
(Wasmtime initial)------------------------------------------------------------------/

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 20:42):

cfallin commented on PR #11815:

(I believe this could be done with git rebase --onto main when on the Wizer branch, before the merge commit)

view this post on Zulip Wasmtime GitHub notifications bot (Oct 08 2025 at 20:42):

cfallin commented on PR #11815:

(Happy to talk about this tomorrow in the Wasmtime meeting, too; the downside is that by rewriting commits it does change all the hashes)

view this post on Zulip Wasmtime GitHub notifications bot (Oct 09 2025 at 19:55):

alexcrichton commented on PR #11815:

Ok I've tested what happens with git bisect with unrelated histories. I created a repo like this:

* commit 953fddf46cba6f53a67cc644d18d37dfc86b3b68 (HEAD -> main)
| Author: Alex Crichton <alex@alexcrichton.com>
| Date:   Thu Oct 9 12:51:18 2025 -0700
|
|     main3
|

*   commit 5daf51f205fbb562ac22bb084b1d9d6a620fc9ed
|\  Merge: a9307e8 709165d
| | Author: Alex Crichton <alex@alexcrichton.com>
| | Date:   Thu Oct 9 12:51:12 2025 -0700
| |
| |     Merge branch 'adjacent'
| |
| * commit 709165d603c4f09fce67027e358ba1604927a0c2 (adjacent)
|   Author: Alex Crichton <alex@alexcrichton.com>
|   Date:   Thu Oct 9 12:49:14 2025 -0700
|
|       adjacent1
|

* commit a9307e87fb2eee68a5515099e8fbf2bd5feee5d6
| Author: Alex Crichton <alex@alexcrichton.com>
| Date:   Thu Oct 9 12:51:10 2025 -0700
|
|     main2
|

* commit 97c3f6070514e30a101e60ed25a0ad6201958b6a
  Author: Alex Crichton <alex@alexcrichton.com>
  Date:   Thu Oct 9 12:49:14 2025 -0700

      main1

and then I ran this bisect session:

$ git bisect start
status: waiting for both good and bad commits
$ git bisect good 97c3f6070514e30a101e60ed25a0ad6201958b6a
status: waiting for bad commit, 1 good commit known
$ git bisect bad 953fddf46cba6f53a67cc644d18d37dfc86b3b68
Bisecting: 2 revisions left to test after this (roughly 1 step)
[709165d603c4f09fce67027e358ba1604927a0c2] adjacent1
$ git bisect skip
Bisecting: 0 revisions left to test after this (roughly 1 step)
[5daf51f205fbb562ac22bb084b1d9d6a620fc9ed] Merge branch 'adjacent'
$ git bisect bad
Bisecting: 1 revision left to test after this (roughly 1 step)
[a9307e87fb2eee68a5515099e8fbf2bd5feee5d6] main2
$ git bisect bad
a9307e87fb2eee68a5515099e8fbf2bd5feee5d6 is the first bad commit
commit a9307e87fb2eee68a5515099e8fbf2bd5feee5d6
Author: Alex Crichton <alex@alexcrichton.com>
Date:   Thu Oct 9 12:51:10 2025 -0700

    main2

 a | 2 ++
 1 file changed, 2 insertions(+)

Basically looks like git bisect figured out how to switch between trees alright.

Overall I'm also more comfortable not rewriting commits/dates/authors with git rebase, so I'm going to stick to this branch's merge strategy of two unrelated histories with one merge commit to join them together

view this post on Zulip Wasmtime GitHub notifications bot (Oct 09 2025 at 20:09):

alexcrichton updated PR #11815.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 09 2025 at 20:10):

alexcrichton merged PR #11815.

Last updated: Dec 06 2025 at 07:03 UTC