Bug report

Expected behavior and actual behavior

When the upstream branch is force-pushed (history rewritten), Nextflow's multi-revision repository strategy does not detect the change. The bare repo silently keeps the old SHA and download() short-circuits with Already-up-to-date, so the pipeline continues to run the stale commit.

Steps to reproduce

1. Run a pipeline pointing at a remote branch (e.g. main) so Nextflow caches it under ~/.nextflow/assets/.repos/<project>/bare/.
2. On the remote, rewrite history of that branch and push with --force.
3. Run Nextflow again with the same revision.

Observed: local refs/heads/<branch> in the bare repo still points at the old commit; the corresponding clones/<oldSha>/ still exists; download() returns Already-up-to-date.

Root cause

MultiRevisionRepositoryStrategy.refSpecForName(...) constructs RefSpecs without the leading + that allows non-fast-forward updates. After a force-push, JGit's FetchCommand records REJECTED for the local ref update (visible via FetchResult.getTrackingRefUpdates()) but does not throw, so the bare repo silently keeps the old SHA. Then revisionToCommitWithBareRepo() resolves to the stale commit, whose clone directory still exists, and download() short-circuits.

Verified

Confirmed on a real reproduction with diagnostic logging:

DEBUG n.s.MultiRevisionRepositoryStrategy - Bare repo fetch update for jorgee/nf-sleep [revision: main]: refs/heads/main <- refs/heads/main => REJECTED (old=3851da8d..., new=d17b807d...)

JGit fetched the new object but refused to move the local branch ref because the update was non-fast-forward.

Affected file

modules/nextflow/src/main/groovy/nextflow/scm/MultiRevisionRepositoryStrategy.groovy