feat(rust): port stack new to native Rust#1513
Conversation
Merge ProtectionsYour pull request matches the following merge protections and will not be merged until they are valid. 🟢 🤖 Continuous IntegrationWonderful, this rule succeeded.
🟢 👀 Review RequirementsWonderful, this rule succeeded.
🟢 Enforce conventional commitWonderful, this rule succeeded.Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 ReviewsWonderful, this rule succeeded.
🟢 📕 PR descriptionWonderful, this rule succeeded.
|
There was a problem hiding this comment.
Pull request overview
This PR ports mergify stack new <NAME> from the Python shim to a native Rust implementation, and removes the Python command + its unit tests to keep a single live implementation during the migration. It also introduces a reusable mergify-stack::trunk module to resolve the trunk ref (<remote>/<branch>) for future native stack subcommands.
Changes:
- Add native Rust implementation of
stack newplus dispatch in the Rustmergifybinary. - Add
mergify-stack::trunkhelpers to mirror Python’s trunk resolution and upstream auto-set behavior. - Remove the Python
stack newimplementation, click registration, and Python unit tests for that subcommand.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
mergify_cli/tests/stack/test_new.py |
Removes Python unit tests for the deleted Python stack new implementation. |
mergify_cli/stack/new.py |
Removes the Python implementation of stack new. |
mergify_cli/stack/cli.py |
Removes click wiring for the Python stack new subcommand. |
crates/mergify-stack/src/trunk.rs |
Adds Rust trunk-resolution module (tracking config → origin/HEAD fallback → auto-set upstream). |
crates/mergify-stack/src/lib.rs |
Exposes new commands and trunk modules from mergify-stack. |
crates/mergify-stack/src/commands/new.rs |
Adds Rust stack new implementation (fetch + branch creation) with unit tests. |
crates/mergify-stack/src/commands/mod.rs |
Introduces the commands module namespace for stack subcommands. |
crates/mergify-cli/src/main.rs |
Adds native dispatch for mergify stack new while keeping other stack subcommands shimmed. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@jd this pull request is now in conflict 😩 |
The Rust binary now serves ``mergify stack new <name>`` natively.
The Python implementation (``mergify_cli/stack/new.py``, its
click registration in ``mergify_cli/stack/cli.py``, and the unit
suite in ``mergify_cli/tests/stack/test_new.py``) is removed in
the same PR — the port-and-delete rule keeps a single live copy
of every command.
This is the first ``stack`` subcommand to land natively; the
rest still flow through the Python shim. The dispatcher peeks at
``argv[0]`` after ``stack`` — when it's ``new``, the rest is
secondary-parsed by clap and dispatched into
``mergify_stack::commands::new``; everything else continues to
forward to ``mergify-py-shim`` verbatim.
``mergify stack new <NAME> [-b REMOTE/BRANCH]
[--checkout/--no-checkout]``:
1. Resolves the base ref. ``--base origin/main`` is used verbatim;
otherwise ``mergify_stack::trunk::get_trunk`` mirrors the Python
``utils.get_trunk`` chain: ``branch.<current>.{remote,merge}``
tracking → ``refs/remotes/origin/HEAD`` fallback → set tracking
on the current branch with a yellow notice → ``StackNotFound``
when both fail.
2. ``git fetch <remote> <branch>`` brings the base up to date.
3. ``git checkout --track -b <name> <base>`` (default) or
``git branch --track <name> <base>`` (``--no-checkout``)
creates the branch.
Exit-code mapping matches Python: ``StackNotFound`` when the
trunk can't be resolved, ``GenericError`` for fetch/branch
failures, ``Success`` on the happy path.
The new ``mergify-stack::trunk`` module is reusable by future
``stack drop``/``stack edit``/``stack sync`` ports — the helpers
``git_get_branch_name``, ``git_get_target_branch``,
``git_get_target_remote``, and ``get_trunk`` are public.
``mergify stack new --help`` is now served by clap; the bare
``mergify stack --help`` still shims to Python and lists the
remaining Python-only subcommands.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Change-Id: Ia8c23565155a0a64bd4f8b4b66fd493ab1fc0cc5
50050a2 to
e5b00a8
Compare
Revision history
|
|
This pull request is part of a Mergify stack:
|
Merge Queue Status
This pull request spent 12 seconds in the queue, including 2 seconds running CI. Required conditions to merge
|
The Rust binary now serves
mergify stack new <name>natively.The Python implementation (
mergify_cli/stack/new.py, itsclick registration in
mergify_cli/stack/cli.py, and the unitsuite in
mergify_cli/tests/stack/test_new.py) is removed inthe same PR — the port-and-delete rule keeps a single live copy
of every command.
This is the first
stacksubcommand to land natively; therest still flow through the Python shim. The dispatcher peeks at
argv[0]afterstack— when it'snew, the rest issecondary-parsed by clap and dispatched into
mergify_stack::commands::new; everything else continues toforward to
mergify-py-shimverbatim.mergify stack new <NAME> [-b REMOTE/BRANCH] [--checkout/--no-checkout]:--base origin/mainis used verbatim;otherwise
mergify_stack::trunk::get_trunkmirrors the Pythonutils.get_trunkchain:branch.<current>.{remote,merge}tracking →
refs/remotes/origin/HEADfallback → set trackingon the current branch with a yellow notice →
StackNotFoundwhen both fail.
git fetch <remote> <branch>brings the base up to date.git checkout --track -b <name> <base>(default) orgit branch --track <name> <base>(--no-checkout)creates the branch.
Exit-code mapping matches Python:
StackNotFoundwhen thetrunk can't be resolved,
GenericErrorfor fetch/branchfailures,
Successon the happy path.The new
mergify-stack::trunkmodule is reusable by futurestack drop/stack edit/stack syncports — the helpersgit_get_branch_name,git_get_target_branch,git_get_target_remote, andget_trunkare public.mergify stack new --helpis now served by clap; the baremergify stack --helpstill shims to Python and lists theremaining Python-only subcommands.
Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com