Rebase sierra-release-branch onto upstream release v0.17.94 - #4
Merged
Merged
Conversation
jaked
force-pushed
the
sierra-release-branch-rebased
branch
from
August 18, 2026 20:54
674293b to
e550b19
Compare
vbud
approved these changes
Aug 18, 2026
jaked
force-pushed
the
sierra-release-branch
branch
from
August 18, 2026 21:19
51df737 to
e550b19
Compare
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.
I want to pick up 99designs#4086 which should make it so we don't regenerate so many files when making GraphQL type changes.
Replays the 3 Sierra-only commits from
sierra-release-branchonto upstream99designs/gqlgentagv0.17.94(690713b8, released 2026-07-09) — the latest upstream release.The branch was previously based on release tag v0.17.86 (
4079e8dc), so rebasing onto a release tag rather than a movingmasterpreserves that property: the fork stays anchored to a released, tagged upstream version.Note that
sierra-inc/gqlgen's own master was 208 commits behind 99designs, so it was not a useful target.Commits
99bfeedfb7ba2fafe550b197Conflict resolution
codegen/field.go— upstream changedcontains(...)toslices.Contains(...)on the exact line whose body #3 rewrote. Took upstream'sslices.Contains.plugin/federation/federation.go— pure formatting conflict; took upstream's.Dropped churn (intentional). Commit #3 originally bundled unrelated
WriteString(fmt.Sprintf(...))→fmt.Fprintf(...)lint changes acrosscodegen/directive.go,codegen/field.go, andplugin/federation/federation.go. Upstream has since made those exact conversions itself, so the replayed commit is now purely the sync.Map cache change plus its tests.git range-diffconfirms commit #1 is otherwise byte-identical and #2 differs only in surrounding context.Semantic fix (not a textual conflict). Upstream added a
parentIsDeferredFragment boolparameter tocollectFields. Three call sites in the new benchmark/stress tests were updated to passfalse, matching the top-levelCollectFieldsentry point ingraphql/executable_schema.go. Git could not detect this — it rebased without conflict and simply failed to compile, surfacing only undergo vet.Verification
All run at this branch tip:
go build ./...— cleango vet ./...— cleango test ./...— full suite passesgo generate ./...— no diff, working tree cleanThis is a history rewrite, not an incremental change. Do not merge normally — a merge commit would defeat the rebase and reintroduce the pre-rebase history. Instead force-update
sierra-release-branchto this tip:sierra-release-branchis untouched until someone does that.🤖 Generated with Claude Code