mirror of
https://github.com/MadsLorentzen/ai-job-search.git
synced 2026-09-17 00:26:26 +00:00
Forks tracking this template face a weekly "which of these commits do I actually care about?" question. check_upstream_updates.py answers it at the file level (version stamps); this adds the commit-level half. tools/upstream_triage.py walks the commits a fork is behind and splits them into "worth reviewing" and "probably skip". Work already ported drops off on its own via git patch-id, commits touching only files the fork removed are set aside, and SHAs in .github/upstream-wontport.txt stay hidden. It reports and nothing more - ready-to-run cherry-pick lines, but no merge, push, or PR, since on a fork "applies cleanly" is not "correct". .github/workflows/upstream-watch.yml runs it weekly into one rolling issue. It no-ops on the upstream template (guarded, and pinned by a test) and uses only the built-in GITHUB_TOKEN, so it can never write outside its own fork. The two tools point at each other in their output; README, SETUP 8, and CHANGELOG introduce them together. Tests cover patch-id matching, relevance filtering, the won't-port list, and the workflow guard - all offline. Co-authored-by: Angelina Lok <angelina@chattermill.io> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Angelina Lok
Claude Opus 4.7
parent
cfd9a9fba1
commit
670d30ae7e
@@ -298,6 +298,16 @@ Upstream keeps improving the methodology files your fork has personalized, so pl
|
||||
python3 tools/check_upstream_updates.py
|
||||
```
|
||||
It compares the `framework_version` markers in your framework files against upstream and lists exactly which methodology files changed, with the diff command for each.
|
||||
|
||||
Two tools answer two different questions, and it's worth running both:
|
||||
- **`check_upstream_updates.py`** — *which of my personalized files changed?* It reads the `framework_version` stamp on each methodology file, so it flags exactly the customized files a release touched.
|
||||
- **`upstream_triage.py`** — *which upstream commits deserve my attention?* It walks the commits you're behind and sorts them into "worth reviewing" vs "probably skip", dropping anything you've already cherry-picked (matched by `git patch-id`, so ported work falls off with no bookkeeping), commits that only touch files your fork removed, and SHAs you've listed in `.github/upstream-wontport.txt`. It's report-only — it prints ready-to-run `git cherry-pick` lines but never merges, pushes, or opens a PR, because on a fork "applies cleanly" isn't "correct".
|
||||
|
||||
```bash
|
||||
python3 tools/upstream_triage.py --remote upstream
|
||||
```
|
||||
|
||||
Forks also inherit a `.github/workflows/upstream-watch.yml` that runs this weekly and writes the result into a single rolling issue (it no-ops on the upstream template itself, and stays disabled on a fork until you enable Actions).
|
||||
3. **Merge normally.** `git merge upstream/master` (or `git pull`) three-way-merges upstream's edits around your personalization; because methodology edits rarely touch the lines `/setup` filled in, most updates land cleanly. A conflict in a personalized file is a *feature*, not a failure — it means upstream changed methodology in a section you customized, and the version marker plus its changelog commit tell you why. Resolve by keeping your data and adopting the methodology change around it.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Reference in New Issue
Block a user