Skip to content

[pull] master from kevoreilly:master - #540

Merged
pull[bot] merged 2 commits into
threatcode:masterfrom
kevoreilly:master
Sep 21, 2026
Merged

pull[bot] merged 2 commits into
threatcode:masterfrom
kevoreilly:master

Conversation

@pull

@pull pull Bot commented Sep 21, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

karlhiramoto and others added 2 commits September 21, 2026 06:16
…ning (#3245)

* Fix ResultServer file collisions with SHA256 deduplication and versioning

* Fix CAPE processing crash when [magika] config section is missing and preserve dropfile name order

* Use fast mocks in test_cape_processing_without_magika_config
* Add utils/agent_worktree.py for isolated PR/branch checkouts

Reviewing a PR or reproducing a bug against another branch currently means
checking it out in your working clone. Most clones carry uncommitted work, so
that is either unsafe or requires manual git worktree plumbing: figuring out
which fork the head branch lives in, fetching it under a sane name, setting
upstream, and cleaning up afterwards.

utils/agent_worktree.py wraps that:

  new --pr <id>       resolve the head fork via gh, fetch, branch, check out
  new --branch <name> / --from <ref>
  list / path / update / remove / cleanup / info

It is stdlib-only and repository-agnostic. Worktrees it creates are tagged
with metadata inside the git admin directory, so nothing extra appears in
git status and cleanup only ever touches its own worktrees. remove and
cleanup refuse to discard uncommitted changes or unpushed commits without
--force, and the main worktree can never be removed.

tests/test_agent_worktree.py covers the CLI against throwaway local
repositories; no network, credentials or CAPE configuration required.

SKILLS.md gains sections on the local development environment, isolated
checkouts, and codebase behaviours that cause silent failures.

* agent_worktree: handle fork remote layouts

Clones that follow the fork convention have origin pointing at the
contributor's fork and upstream at the canonical repository. Two things broke
there:

* repo_slug() preferred origin, so 'gh pr view' was asked about the fork
  instead of the repository the PR was opened against. upstream now wins when
  it is configured; clones made straight from the canonical repo are
  unaffected because they have no upstream.
* 'new --branch' fetched from origin only and failed outright if the branch
  lived upstream. It now tries origin, then upstream, then any other remote,
  and reports which one it used.

A missing branch is now a clear error naming the remotes that were tried.

* agent_worktree: do not call work unpushed when it lives on another remote

The removal guard compared HEAD against the tracked upstream only. A review
branch normally tracks the branch it will merge into while its commits are
pushed to a fork, so 'rev-list @{upstream}..HEAD' is non-zero even though
nothing is at risk, and cleanup refused to remove a worktree whose work was
safely published.

The guard now treats work as unpushed only when no remote-tracking ref
contains HEAD at all, which is the condition that actually matters.
@pull pull Bot locked and limited conversation to collaborators Sep 21, 2026
@pull pull Bot added the ⤵️ pull label Sep 21, 2026
@pull
pull Bot merged commit e456bc0 into threatcode:master Sep 21, 2026
2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants