docs(git-workflow): warn about destructive checkout and identical hunks - #138
Merged
Conversation
Three lessons from one session, all reference-only: `git checkout <ref> -- <path>` overwrites the working tree with no warning and no reflog entry. Used to restore a file after measuring a baseline, it silently discarded an uncommitted fix, and the following commit went out without it. `git show <ref>:<path>` already documented just above is the non-destructive answer. Chaining `git push` behind a filtered test run with `&&` pushes on a red suite, because grep exits 0 on matching the word FAILURES. Two independent PRs that both need the same hunk can carry it byte-identically, which git merges once in any order. That removes the merge-order constraint instead of stacking the PRs. Signed-off-by: Sebastian Mendel <github@sebastianmendel.de>
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
github-actions
Bot
added
documentation
There was a problem hiding this comment.
Pull request overview
This PR updates the Git workflow reference documentation to warn about a few easy-to-miss failure modes encountered during parallel PR work, and adds a conflict-resolution technique for handling identical hunks across independent PRs.
Changes:
- Add guidance on avoiding destructive
git checkout <ref> -- <path>when work is uncommitted, with safer alternatives (git show, worktrees). - Document why
&&-chaining agit pushbehind filtered test output can push even when the suite fails, plus a remote verification step. - Add a “byte-identical hunk in both PRs” strategy to remove merge-order constraints when two PRs need the same change.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| skills/git-workflow/references/pull-request-workflow.md | Adds a conflict-resolution pattern for duplicating identical hunks across independent PRs and verifying merge behavior. |
| skills/git-workflow/references/advanced-git.md | Adds warnings and safer patterns around destructive path checkout and &&-chained push pipelines, plus a small cleanup at EOF. |
Suppressed comments (1)
skills/git-workflow/references/advanced-git.md:936
- Same issue as above:
developis repo-specific. Use a placeholder baseline ref so the command can be copied verbatim into repos that don’t have adevelopbranch.
git worktree add /tmp/baseline develop
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- The merge-order loop continued after a conflict, leaving the repo mid-merge and every later result meaningless. Abort and exit instead. - grep -c counts lines, so a multi-line pattern never matches: say to use one distinctive line, and -F to avoid regex surprises in code. - set -o pipefail is not in POSIX sh; lead with the portable rc capture and note where pipefail applies. - "nothing to recover from" was absolute; uncommitted content never reaches the object store, but an editor history or snapshot may hold it. - Replace the hardcoded develop with <base-ref>, and use consistent placeholders in the sed extraction. Signed-off-by: Sebastian Mendel <github@sebastianmendel.de>
|
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.
Came from /retro: yes
Three reference-only additions, all from one session of parallel PR work.
git checkout <ref> -- <path>is destructive and leaves no reflog entry (advanced-git.md). Used to restore a file after measuring a baseline againstdevelop, it silently discarded a fix that was still only in the working tree — and the nextgit addcommitted the file without it. The section it lands in already documentsgit show <ref>:<path>, which is the non-destructive answer, so this only names the trap and points at the tool already described above it.Chaining
git pushbehind a filtered test run with&&pushes on a red suite (advanced-git.md).grep -E 'OK|FAILURES'exits 0 on matching the wordFAILURES, so the chain reads the filter's status, not the runner's. Includes the verification step that actually catches it: fetch the branch back and grep the pushed blob.While writing this PR the same class of failure happened again in this repo — the
end-of-file-fixerhook aborted the commit, the&&-chained push ran anyway and created a remote branch pointing at the unchanged base. The fix that landed is therefore also the demonstration.Two independent PRs needing the same hunk can carry it byte-identically (
pull-request-workflow.md). Git merges the same change at the same place once, in any order, so the merge-order constraint disappears instead of the PRs having to be stacked. Includes the byte-comparison and the throwaway-clone check that proves the property rather than assuming it.No
SKILL.mdchange, so the 500-word budget is untouched.