Tracked result files are overwritten by git pull or reset during a run
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 76/100
Research direction
Read the README and add the guidance to pull before launching a run, avoid pulling or resetting in the run directory while it is running, and commit results afterward. The issue defers the results-directory redesign to a future structural change. Done when the README explains this workflow clearly.
Written by the indexing model from the issue text.
Description
The per-physiology result files (*_counts.tsv, *_mcc.tsv, *_castor-ltp.tsv, the summaries) are tracked in git, so any git pull or git reset --hard in the run directory while a run is in progress overwrites fresh results with the committed ones. That happened on 2026-11-05: pulling a review fix mid-run put the 2024 numeric results and rank-all counts back, and the first v1.0.5 summary silently contained 2024 numbers for those rows. The fold CSVs are untracked, so they survived.
Two cheap protections:
- README: never pull or reset in the run directory while a run is in progress; pull before launching, commit results after.
- The 01 scripts write results into the working tree. Writing to a
results/<date>/directory that the summary script reads from, and copying into place only when a run is complete, would make a pull harmless. Alternatively stop tracking the per-physiology files and keep onlyvalidation_summary.tsvplus the dated tarballs in git.
I'd do the README line now and the results directory with the next structural change.
Drafted with Claude Code.
- Dominant language
- R
- Stars
- 0
- Forks
- 0
- Avg merge
- 4h 56m
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from waldronlab/taxPProValidation
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 1/5 Under an hour Newbie friendliness 94/100
All issues in waldronlab/taxPProValidation
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 95/100
OHDSI/CohortGenerator#281 ·