You have two ways to implement a change. Both look reasonable. Which one should you keep?
Git branches and worktrees give you separate places to experiment. But you still need to run checks, remember which result belongs to which implementation, and explain your decision.
I built ParallelEarth, a VS Code extension that groups alternatives and recorded check results into one experiment.
Here’s a reproducible example using real Git worktrees.
The example: booking reconciliation
The repository includes a small booking-reconciliation fixture with three alternative implementations.
We’ll run the same command against the baseline and two alternatives, leaving the third untested. This demonstrates an important distinction: passing, failing and having no evidence are different states.
- Run the demonstration
You’ll need Git, npm and Node.js 22.17 or later.
git clone https://github.com/shubhammaji1/parallel-earth.git
cd parallel-earth
npm install --ignore-scripts
npm run demo
Run these commands from a checkout you trust. The demo builds the project and executes the included fixture checks.
It creates a separate fixture repository, a baseline worktree and three alternative worktrees. Your development checkout’s booking implementation remains unchanged.
- Inspect the results
The demo runs:
`node --test test/reconcile.test.cjs`
against the baseline, Earth A and Earth B.
The resulting comparison is:
Version
Outcome
Baseline
PASSED
A — Deduplicate correctly
PASSED
B — Duplicate regression
REGRESSION
C — Not yet checked
NOT_RUN
REGRESSION means the baseline passed while the alternative failed the matching check under compatible recorded fingerprints.
NOT_RUN means no check result was recorded. It doesn’t mean the implementation failed—or that it works.
The fixture is intentionally constructed to demonstrate these outcomes. It isn’t a benchmark or evidence that the extension detects every regression.
- Read the evidence
Open:
artifacts/booking-report.md
artifacts/booking-report.json
The Markdown report provides a readable comparison. JSON contains retained execution evidence, including recorded command results.
The terminal also prints the location of the generated fixture. Its worktrees remain available for inspection.
Check the implementation, test expectations and command output together. A green command only tells you that the command succeeded; your tests may still miss important behaviour.
Try the same workflow on your project
Install ParallelEarth from the VS Code Marketplace, then:
Run ParallelEarth: Open Home.
Create an experiment from a trusted Git repository and committed revision.
Create named Earths for your alternative approaches.
Open each Earth and make your changes.
Install dependencies independently where needed.
Run matching checks, review the commands and approve execution.
Compare the evidence and export a report.
Earths start from committed code. Your original checkout’s uncommitted files and installed dependencies aren’t automatically copied.
The automated demo uses the project’s core modules. It is separate from this interactive extension workflow.
Why not use worktrees manually?
You absolutely can.
ParallelEarth uses worktrees underneath. Its purpose is to keep the experiment question, alternative implementations, recorded checks and comparison together inside VS Code.
For a straightforward feature, a branch may be enough. This workflow is more useful when you are evaluating competing approaches before choosing one.
Worktrees separate code state; they aren’t security sandboxes. Approved commands run on your machine. Recorded durations are execution details, not performance benchmarks.
Try it and challenge the workflow
Explore the source and report issues
I’d especially appreciate feedback on one question:
Does keeping the alternatives and check evidence together make your decision easier than managing worktrees manually?
Top comments (0)