Skip to content

merge queue: checking #1880 on main (e265eb5), stacked on #1879 - #1885

Closed
mergify[bot] wants to merge 4 commits into
mainfrom
mergify/merge-queue/9ad4461ce7
Closed

mergify[bot] wants to merge 4 commits into
mainfrom
mergify/merge-queue/9ad4461ce7

Conversation

@mergify

@mergify mergify Bot commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

🎉 This pull request has been checked successfully and will be merged soon. 🎉

#1880 is queued for merge on branch main (e265eb5).

Stacked behind 1 pull request queued ahead of this batch, not part of it. These checks run on a tip that also carries its commits, so a failure here can come from it as much as from #1880.

Queued ahead of this batch:

This pull request has been created by Mergify to speculatively check the mergeability of #1880.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule default for merge:

Required conditions to stay in the queue:

---
all_scopes: false
checking_base_sha: 1c18999c0759390203e651fa450db16e0dbe9293
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 1880
    scopes: []
scopes: []
...

sileht and others added 4 commits October 5, 2026 14:53
`mergify ci scopes` decodes `git diff` output lossily, so a Latin-1
`critical/caf\xe9.txt` reaches the scope globs as
`critical/caf\u{FFFD}.txt`. The ticket read that as corruption and
leaned toward hard-erroring like `mergify_stack`'s `run_git_capture`.

It is not corruption. The engine scopes a pull request from GitHub's
files API, and that API reports the same path with the same U+FFFD
replacement (checked on a sandbox repository holding a Latin-1 and a
Shift-JIS name). The lossy decode is therefore the name the engine
matches. An error would fail CI on a pull request the engine scopes
fine, and no pattern in the UTF-8 YAML config can spell the raw bytes.

Keep the decode, say why in the doc comment that used to describe it
as a known defect, and pin both probed names in a test so a later
switch to strict decoding fails loudly. The test helpers now also drop
GIT_INDEX_FILE and friends, since the new one writes the index
directly.

What still differs on such paths, and on any non-ASCII path, is glob
semantics: globset's `?` and `[...]` match bytes, the engine's match
characters, so `caf?.txt` misses `caf\u{FFFD}.txt` here and hits it
there. That is MRGFY-10066; matching.rs no longer claims exact parity.

Fixes MRGFY-8289

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I37852b3d50345f42b6dfe8cca6e1b36c8858a3fb
`mergify ci scopes --base origin/main --head HEAD` is the invocation the
mergify-ci skill documents. Under `actions/checkout`'s default
`fetch-depth: 1` it failed the step with a git error instead of emitting
scopes, for two reasons:

- The fetch asked the remote for `origin/main`, a name only a clone
  knows: "fatal: couldn't find remote ref origin/main". A leading
  `origin/` (or `remotes/origin/`, `refs/remotes/origin/`) is now
  stripped from the fetch source; the local ref name is unchanged.
  `feature/x` is left alone, only the remote we fetch from counts as a
  prefix.
- With that fixed, `--deepen` only deepened `main`. HEAD is never
  fetched by name, so its depth-1 boundary kept hiding its parents and
  the loop ended with "cannot find a common ancestor". The `--deepen`
  rounds now also ask for every commit listed in the clone's `shallow`
  file, so each boundary moves, HEAD's included.

The boundary commits rather than HEAD's SHA: they all came from the
remote, while HEAD can be a commit made on top of the checkout, which
the remote refuses and which would fail the whole fetch. They join only
the `--deepen` rounds, never the first `--depth` one, which would cut a
history the checkout already has.

Pull request events with a head SHA were not affected: both SHAs are
fetched. The other auto-detected references that use `HEAD` as head
(the `HEAD^` fallback outside GitHub Actions, a push without `before`)
get the boundary deepening too.

Fixes MRGFY-8290

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: If4ba206ad2a6f84fe06a47ba62c1e9149b95c104
@mergify
mergify Bot deployed to Mergify Merge Protections October 5, 2026 15:02 Active
@mergify
mergify Bot deployed to func-tests-live October 5, 2026 15:03 Active
@mergify mergify Bot closed this Oct 5, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/9ad4461ce7 branch October 5, 2026 15:11

This branch was successfully deployed

2 active deployments
func-tests-live — 5f7716ab Deployed Oct 5, 2026 by mergify[bot] via live-tests #1977
Mergify Merge Protections — 5f7716ab Deployed Oct 5, 2026 by mergify[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant