V0.7.5/trunk first repo - #30
Merged
Merged
Conversation
Split initialization into Initialize and Push Remote workflows so users can provision the trunk-first git structure before the remote URL is available. Add Step 0 to detect mode, Push Remote Workflow (Steps P1-P3) with branch and remote validation, and updated summary with push-remote guidance. Extends evals with test cases for post-initialization remote push scenarios.
Greptile SummaryThis PR adds a
Confidence Score: 4/5Safe to merge with a small fix to the Step 4 summary template, which always shows 'remote: not configured' even when a remote was configured in Step 3. The dedicated Push Remote Workflow with its branch and tree validation is well-designed and the eval coverage is solid. The concrete defect is in the Step 4 summary template: it always directs the user to invoke 'push remote' even when the remote was already added and main was already pushed in Step 3, giving incorrect next steps for the common init-with-remote path. skills/trunk-first-repo/SKILL.md — the Step 4 summary template (lines 96–113) and the relationship between Step 3a and the Push Remote Workflow. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A([User invokes trunk-first-repo]) --> B{Says 'push remote'?}
B -- Yes --> PW[Push Remote Workflow]
B -- No --> IW[Initialize Workflow]
IW --> S1[Step 1: Collect Parameters]
S1 --> S2[Step 2: git init + orphan main + seed commit + feature branch]
S2 --> S3{Remote URL provided?}
S3 -- Yes --> S3A[Step 3: git remote add origin
git push -u origin main:main]
S3 -- No --> S4[Step 4: Show summary]
S3A --> S4
S4 --> FC[User commits first files on feature branch]
FC --> S3a[Step 3a: git push -u origin main:main
git push -u origin HEAD]
PW --> P1[Step P1: Check current branch
Block if on main
Verify main is empty]
P1 --> P2{origin exists?}
P2 -- Yes --> P3
P2 -- No, URL given --> AddOrigin[git remote add origin URL]
P2 -- No, no URL --> AskURL[Ask for URL]
AddOrigin --> P3
AskURL --> P3
P3[Step P3: git push -u origin main:main
git push -u origin HEAD] --> Done([Tell user to open PR])
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A([User invokes trunk-first-repo]) --> B{Says 'push remote'?}
B -- Yes --> PW[Push Remote Workflow]
B -- No --> IW[Initialize Workflow]
IW --> S1[Step 1: Collect Parameters]
S1 --> S2[Step 2: git init + orphan main + seed commit + feature branch]
S2 --> S3{Remote URL provided?}
S3 -- Yes --> S3A[Step 3: git remote add origin
git push -u origin main:main]
S3 -- No --> S4[Step 4: Show summary]
S3A --> S4
S4 --> FC[User commits first files on feature branch]
FC --> S3a[Step 3a: git push -u origin main:main
git push -u origin HEAD]
PW --> P1[Step P1: Check current branch
Block if on main
Verify main is empty]
P1 --> P2{origin exists?}
P2 -- Yes --> P3
P2 -- No, URL given --> AddOrigin[git remote add origin URL]
P2 -- No, no URL --> AskURL[Ask for URL]
AddOrigin --> P3
AskURL --> P3
P3[Step P3: git push -u origin main:main
git push -u origin HEAD] --> Done([Tell user to open PR])
Prompt To Fix All With AIFix the following 3 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 3
skills/trunk-first-repo/SKILL.md:96-113
**Summary template hardcodes "not configured" regardless of Step 3 outcome**
Step 4 always renders `remote: not configured (add later with \`git remote add origin <url>\`)` and instructs the agent to direct the user to invoke `push remote <url>` — but Step 3 may have already added the remote and pushed `main:main`. An agent following this template literally will display misleading post-init information whenever the user provided a URL, and the "Next steps" list prompts unnecessary `push remote` invocation for a remote that is already configured.
The template should branch on whether a remote was configured: when one was provided, confirm the remote URL and replace steps 2–4 with only `git push -u origin HEAD` once feature-branch work is ready.
### Issue 2 of 3
skills/trunk-first-repo/SKILL.md:67-94
**Step 3a covers the same scenario as Push Remote Workflow without its safety checks**
Step 3a's second branch — "If the remote was added only after the first feature commit" — is functionally identical to the Push Remote Workflow but omits `git branch --show-current` and `git ls-tree -r --name-only main` guards that Step P1 mandates. An agent following Step 3a for this late-remote scenario would skip those guards entirely.
Consider cross-referencing the Push Remote Workflow for this case, or mirroring the Step P1 checks inline.
### Issue 3 of 3
skills/trunk-first-repo/SKILL.md:67-84
**Step 3a redundantly re-pushes `main:main` when the remote was already set up in Step 3**
When the user provided a remote URL during init, Step 3 already ran `git push -u origin main:main`. Step 3a unconditionally repeats that push before pushing `HEAD`. The second push is a silent no-op but may confuse users who see a push command appear to run without effect. A guard or an explicit note that the first command is a no-op when already pushed in Step 3 would clarify intent.
Reviews (1): Last reviewed commit: "♻️ add push-remote workflow to trunk-fir..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
96
to
+113
| @@ -65,11 +104,68 @@ After initialization, display a summary: | |||
| feature branch: v0.1.0/init (current — start working here) | |||
| remote: not configured (add later with `git remote add origin <url>`) | |||
|
|
|||
| Next steps: | |||
| 1. Stage and commit your files on this branch | |||
| 2. Push the feature branch and open a PR to main | |||
| 3. After review, merge the PR — main stays clean | |||
| ``` | |||
| Next steps: | |||
| 1. Stage and commit your files on this branch | |||
| 2. When the remote is ready, invoke `push remote <url>` from this branch | |||
| 3. Push main first with `git push -u origin main:main` | |||
| 4. Push the feature branch with `git push -u origin HEAD` and open a PR to main | |||
| 5. After review, merge the PR — main stays clean | |||
| ``` | |||
There was a problem hiding this comment.
Step 4 always renders remote: not configured (add later with \git remote add origin `)and instructs the agent to direct the user to invokepush remote — but Step 3 may have already added the remote and pushedmain:main. An agent following this template literally will display misleading post-init information whenever the user provided a URL, and the "Next steps" list prompts unnecessary push remote` invocation for a remote that is already configured.
The template should branch on whether a remote was configured: when one was provided, confirm the remote URL and replace steps 2–4 with only git push -u origin HEAD once feature-branch work is ready.
Prompt To Fix With AI
This is a comment left during a code review.
Path: skills/trunk-first-repo/SKILL.md
Line: 96-113
Comment:
**Summary template hardcodes "not configured" regardless of Step 3 outcome**
Step 4 always renders `remote: not configured (add later with \`git remote add origin <url>\`)` and instructs the agent to direct the user to invoke `push remote <url>` — but Step 3 may have already added the remote and pushed `main:main`. An agent following this template literally will display misleading post-init information whenever the user provided a URL, and the "Next steps" list prompts unnecessary `push remote` invocation for a remote that is already configured.
The template should branch on whether a remote was configured: when one was provided, confirm the remote URL and replace steps 2–4 with only `git push -u origin HEAD` once feature-branch work is ready.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
+67
to
+94
| ### Step 3a: First Feature Push | ||
|
|
||
| After the user commits the first project files on the feature branch, push in this order: | ||
|
|
||
| ```bash | ||
| git push -u origin main:main | ||
| git push -u origin HEAD | ||
| ``` | ||
|
|
||
| This order matters. `main` must exist on the remote before the feature branch is pushed so hosts such as GitHub do not make the feature branch the default branch for a brand-new remote. | ||
|
|
||
| If the remote was added only after the first feature commit, still run the same order from the feature branch: | ||
|
|
||
| ```bash | ||
| git remote add origin {REMOTE_URL} | ||
| git push -u origin main:main | ||
| git push -u origin HEAD | ||
| ``` | ||
|
|
||
| Do not manually delete project files from the working tree to "clean" `main`. When the user is worried about files appearing on `main`, explicitly explain that untracked or ignored checkout files can remain visible in the directory but are not part of the `main` branch. If the user needs to verify that `main` is empty, inspect the branch tree instead of the checkout directory: | ||
|
|
||
| ```bash | ||
| git ls-tree -r --name-only main | ||
| ``` | ||
|
|
||
| An empty output means `main` contains only the seed commit. Untracked or ignored files in the checkout directory are not part of `main`. | ||
|
|
||
| If the feature branch was accidentally pushed before `main`, push `main` next and change the remote repository's default branch to `main` before opening the PR. |
There was a problem hiding this comment.
Step 3a's second branch — "If the remote was added only after the first feature commit" — is functionally identical to the Push Remote Workflow but omits git branch --show-current and git ls-tree -r --name-only main guards that Step P1 mandates. An agent following Step 3a for this late-remote scenario would skip those guards entirely.
Consider cross-referencing the Push Remote Workflow for this case, or mirroring the Step P1 checks inline.
Prompt To Fix With AI
This is a comment left during a code review.
Path: skills/trunk-first-repo/SKILL.md
Line: 67-94
Comment:
**Step 3a covers the same scenario as Push Remote Workflow without its safety checks**
Step 3a's second branch — "If the remote was added only after the first feature commit" — is functionally identical to the Push Remote Workflow but omits `git branch --show-current` and `git ls-tree -r --name-only main` guards that Step P1 mandates. An agent following Step 3a for this late-remote scenario would skip those guards entirely.
Consider cross-referencing the Push Remote Workflow for this case, or mirroring the Step P1 checks inline.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
+67
to
+84
| ### Step 3a: First Feature Push | ||
|
|
||
| After the user commits the first project files on the feature branch, push in this order: | ||
|
|
||
| ```bash | ||
| git push -u origin main:main | ||
| git push -u origin HEAD | ||
| ``` | ||
|
|
||
| This order matters. `main` must exist on the remote before the feature branch is pushed so hosts such as GitHub do not make the feature branch the default branch for a brand-new remote. | ||
|
|
||
| If the remote was added only after the first feature commit, still run the same order from the feature branch: | ||
|
|
||
| ```bash | ||
| git remote add origin {REMOTE_URL} | ||
| git push -u origin main:main | ||
| git push -u origin HEAD | ||
| ``` |
There was a problem hiding this comment.
main:main when the remote was already set up in Step 3
When the user provided a remote URL during init, Step 3 already ran git push -u origin main:main. Step 3a unconditionally repeats that push before pushing HEAD. The second push is a silent no-op but may confuse users who see a push command appear to run without effect. A guard or an explicit note that the first command is a no-op when already pushed in Step 3 would clarify intent.
Prompt To Fix With AI
This is a comment left during a code review.
Path: skills/trunk-first-repo/SKILL.md
Line: 67-84
Comment:
**Step 3a redundantly re-pushes `main:main` when the remote was already set up in Step 3**
When the user provided a remote URL during init, Step 3 already ran `git push -u origin main:main`. Step 3a unconditionally repeats that push before pushing `HEAD`. The second push is a silent no-op but may confuse users who see a push command appear to run without effect. A guard or an explicit note that the first command is a no-op when already pushed in Step 3 would clarify intent.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
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
2 participants
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.
This pull request updates the
trunk-first-reposkill to support a safer and more robust workflow for pushing to a new remote after initializing a trunk-based repository. The main improvements clarify and automate the process of pushing themainbranch before feature branches, both during and after initialization, and provide explicit instructions and safeguards to prevent common mistakes (such as accidentally making a feature branch the default branch or pushing unwanted files tomain). The documentation, skill description, and evaluation tests are updated to reflect these enhancements.Skill and Workflow Enhancements:
skills/trunk-first-repo/SKILL.md: Adds a "Push Remote Workflow" for safely pushingmainand feature branches to a new remote even after initialization, including checks to avoid pushing frommain, verifying the empty state ofmain, and explaining the correct push order. The workflow now explicitly recommends usinggit push -u origin main:mainfrom the feature branch and clarifies that untracked/ignored files are not part ofmainunless committed. [1] [2] [3]skills/trunk-first-repo/SKILL.md: Updates the skill description to mention support for a later "push remote" mode and the safe push order.skills/trunk-first-repo/SKILL.md: Updates the day-to-day workflow to include the new push order and steps.Documentation Updates:
README.md: Updates thetrunk-first-repoentry to describe the new "push remote" capability, clarifies push order, and highlights the safer first push process. [1] [2]Test and Evaluation Improvements:
skills/trunk-first-repo/evals/evals.json: Updates and adds evaluation cases to test the new push remote workflow, including checks for pushingmainby ref, not switching branches unnecessarily, and verifying the empty state ofmain. [1] [2]