Fix deepening of shallow clones in latest git#1221
Merged
ecraig12345 merged 1 commit intomainfrom Apr 29, 2026
Merged
Conversation
ed1d17b to
4de238b
Compare
4de238b to
708dcfb
Compare
christiango
approved these changes
Apr 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Something in git 2.54.0 (which seems to be rolling out on GitHub Actions agents as of yesterday) either introduced or surfaced an issue with how beachball handles
git fetchoperations and attempting to deepen shallow clones:When a CI shallow clone doesn't have a fetch refspec configured for the target branch (common with
actions/checkoutsingle-branch clones),git fetch origin mainupdatesFETCH_HEADbut doesn't moverefs/remotes/origin/main. Subsequentgit fetch --deepen=N origin maincalls have the same problem, sogit merge-base origin/main HEADkeeps failing even after deepening, and beachball falls back to a full unshallow unnecessarily.A secondary workaround existed in
ensureSharedHistoryto detect this case and rungit remote set-branches --addbefore fetching — but this only ran when the tracking ref was completely absent, leaving the bug open for cases where the ref existed but fetch config was narrow.Fix
gitFetchnow constructs a fully qualified refspec for every fetch, guaranteeing that the local tracking ref is updated regardless of what's inremote.origin.fetch:In
git fetch <remote> +<src>:<dst>:<src>refs/heads/${branch}is resolved against the remote's advertised refs, not local refs, so it doesn't impact a local${branch}tracking a different remote. The fully qualified ref is unambiguous. (An earlier version of this change used a bare branch name, which can be silently misresolved, causing git to treat the ref as absent and delete the local tracking ref.)<dst>refs/remotes/${remote}/${branch}is resolved locally and only moves the tracking ref for the remote branch, not the localrefs/heads/${branch}or its tracking config.This also removes the
git config --get-all+git remote set-branches --addblock fromensureSharedHistory, since it's no longer needed.Also in this commit
gitFetchparamsremoteandbranchare now required (they were always passed together; the optional form was dead code).ensureSharedHistorynow consistently useBeachballError.