fix(forgejo): auto-merge rebase fetches base into remote-tracking ref #61

Merged

navigator merged 1 commit from fix/auto-merge-rebase-refspec into main

2026-05-25 16:24:50 -03:00

navigator commented

2026-05-25 16:22:45 -03:00

Owner

Summary

The rebase path added in #44 cloned with --branch <head> (partial clone, no main locally), then ran git fetch origin main and git rebase origin/main. A plain git fetch origin <ref> updates FETCH_HEAD but does not create refs/remotes/origin/<ref> in a partial clone where it didn't already exist — so git rebase origin/main died with fatal: invalid upstream 'origin/main' and the resolver gave up with exit 5.

Reproduced on PR #59 (Chipyard install) and #60 (tapeout RFQ): both stuck needs-rebase for ~6 minutes with pr-approver kicking the same failure every 60s.

Change

One-line: use an explicit refspec that targets the remote-tracking ref directly:

- git fetch --quiet origin "$base_ref"
+ git fetch --quiet origin "+refs/heads/${base_ref}:refs/remotes/origin/${base_ref}"

The + allows non-fast-forward updates to the remote-tracking ref, matching the implicit behaviour of a default fetch refspec on a normal clone.

Test plan

Verified end-to-end on #59: rebase clone fetched main into refs/remotes/origin/main, git rebase origin/main succeeded, force-push went through, merge HTTP 200.
Verified on #60 (this PR's cascade) — see merge log.

## Summary The rebase path added in #44 cloned with `--branch <head>` (partial clone, no `main` locally), then ran `git fetch origin main` and `git rebase origin/main`. A plain `git fetch origin <ref>` updates `FETCH_HEAD` but does **not** create `refs/remotes/origin/<ref>` in a partial clone where it didn't already exist — so `git rebase origin/main` died with `fatal: invalid upstream 'origin/main'` and the resolver gave up with exit 5. Reproduced on PR #59 (Chipyard install) and #60 (tapeout RFQ): both stuck `needs-rebase` for ~6 minutes with pr-approver kicking the same failure every 60s. ## Change One-line: use an explicit refspec that targets the remote-tracking ref directly: ```diff - git fetch --quiet origin "$base_ref" + git fetch --quiet origin "+refs/heads/${base_ref}:refs/remotes/origin/${base_ref}" ``` The `+` allows non-fast-forward updates to the remote-tracking ref, matching the implicit behaviour of a default fetch refspec on a normal clone. ## Test plan - [x] Verified end-to-end on #59: rebase clone fetched main into `refs/remotes/origin/main`, `git rebase origin/main` succeeded, force-push went through, merge HTTP 200. - [x] Verified on #60 (this PR's cascade) — see merge log.

navigator added 1 commit

2026-05-25 16:22:45 -03:00

fix(forgejo): auto-merge rebase fetches base into remote-tracking ref

build / scalafmt-check (pull_request) Successful in 3s

Details

build / sbt-compile (pull_request) Successful in 3s

Details

build / shell-lint (pull_request) Successful in 11s

Details

a514887689

The previous rebase_and_push cloned with `--branch <head_ref>` (so the
local repo only had the head branch), then ran `git fetch origin <base>`.
A plain `git fetch origin <base>` updates FETCH_HEAD but does NOT create
or update `refs/remotes/origin/<base>` when that remote-tracking ref
doesn't already exist in the partial clone. The subsequent
`git rebase origin/<base>` then died with:

    fatal: invalid upstream 'origin/main'

Observed on PR #59 (Chipyard install) and #60 (tapeout RFQ docs) — both
hit "behind base" on first attempt, both failed to rebase, both stayed
needs-rebase and the pr-approver kicked the same exit-5 path every
minute.

Fix: explicit refspec on the fetch creates the remote-tracking ref
unconditionally:

    git fetch origin "+refs/heads/<base>:refs/remotes/origin/<base>"

The leading `+` allows non-fast-forward update of the remote-tracking
ref, matching the implicit behaviour of a default fetch refspec.