Repository navigation
fix(pull): fetch the splices a conflicted pull brings in - #493
Open
roschaefer wants to merge 6 commits into
Open
roschaefer wants to merge 6 commits into
roschaefer wants to merge 6 commits into
Conversation
A pull that stopped on a conflict hadn't yet fetched the splices the merge brings in: it fetches them after a merge, and the conflict ends the run first. Once the conflict was committed, status reported such a splice as never fetched, and push refused it until a 'git splice fetch'. The commit the pull cherry-picks is there during the conflict, with the .splice files of the splices below as the upstream has them. The pull now fetches what they name before it stops.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 23 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
With --rebase the pull commit is made without a conflict; the conflict comes while the monorepo's own commits are rebased onto it, so there is no CHERRY_PICK_HEAD. The pull commit is the rebase's onto, and has the .splice files below as the upstream has them. A default-pin those files name is fetched too, tag or commit. A new upstream whose fetch fails gives up the key it just got, as fetch does.
The fetch below a conflicted pull had its own fetch path: it read the .splice files with a regex, skipped the checks fetch makes on them, labelled several upstreams alike, and sent no fetch event for --exec and pauses. Commands now read a splice's .splice from a chosen revision, so the conflicted commit's files go through prepare_fetch, download and finish as every other fetch does.
roschaefer
marked this pull request as ready for review
November 13, 2026 19:49
…conflict Review findings on the fetch below a conflicted pull: - A failed fetch there wasn't in the run's "Failed:" list, and an error ended the run before its summary of what's still to pull. - With rebase.backend=apply, the rebase's onto is in rebase-apply/, so nothing was fetched. - The splices below forgot the upstream the conflicted splice was pulled from, e.g. --upstream's, whose default branch they follow. - The glob pathspec also matched the conflicted splice itself, and folder names with glob characters; nested_splices lists them instead.
This branch has not been deployed
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.
A pull that stopped on a conflict hadn't yet fetched the splices the merge brings in: it fetches them after a merge, and the conflict ends the run first. Once the conflict was committed,
statusreported such a splice as never fetched, andpushrefused it until agit splice fetch.The commit the pull brings in is there during the conflict: as
CHERRY_PICK_HEAD, or with--rebaseas the commit the monorepo's own commits are rebased onto. It has the.splicefiles of the splices below as the upstream has them. Before it stops, the pull now fetches what they name that isn't here yet: the upstream itself, the synced commit, or the pin. Which side's.splicestays is up to how the conflict is resolved, so a splice the resolution drops may have been fetched for nothing.To go through the same fetch as everywhere else (checks on the
.splicefiles, labels, pins, key cleanup, the fetch event for--execand pauses), commands can now read a splice's.splicefrom a revision other thanHEAD.Which upstreams to fetch is decided the way
prepare_splice_reloaddecides it after a clean merge, but written out again: that function compares with the.spliceloaded before the merge, which a conflict stop doesn't have. Sharing one rule would be a follow-up.Fixes #429.
#492 tried fetching the whole tree before the first merge instead. It cost about +440 lines, and the walk kept having to copy rules the merge already has (pins, inherited default branches,
--upstream,--branch, copies of a splice inside itself). This takes about +120.