6 ms·
You have never split your working tree changes into separate commits?
by yes_man 8mo ago
You have never split your working tree changes into separate commits?
- forgotpwd16 8mo agoIrrelevant question. In README has: >Built in public as a learning-by-doing project So, either the entire project was already written and being uploaded one file at the time (first modification since lowest commit mentioned is README update: https://github.com/whispem/minikv/commit/6fa48be1187f596dde869468b4895a157891f683 https://github.com/whispem/minikv/commit/6fa48be1187f596dde8..., clearly AI generated and clearly AI used has codebase/architecture knowledge), and this claim is false, or they're implementing a new component every 30s.
- johnbellone 8mo agoI am not going to pretend to know what this person did, but I've definitely modified many things at once and made distinct commits after the fact (within 30s). I do not find it that abnormal.
- whispem 8mo agoThanks a lot! I make distinct commits "every 30s" because I'm focused and I test my project. If the CI is green, I don't touch of anything. If not, I work on the project until the CI is fully green.
- jabron 8mo agoWhat does that mean? You got feedback from the CI within 30 seconds and immediately pushed a fix?
- whispem 8mo agoYes, in minikv, I set up GitHub Actions for automated CI. Every push or PR triggers tests, lint, and various integration checks — with a typical runtime of 20–60 seconds for the core suite (thanks to Rust’s speed and caching). This means that after a commit, I get feedback almost instantly: if a job fails, I see the logs and errors within half a minute, and if there’s a fix needed, I can push a change right away. Rapid CI is essential for catching bugs early, allowing fast iteration and a healthy contribution workflow. I sometimes use small, continuous commits (“commit, push, fix, repeat”) during intense development or when onboarding new features, and the fast CI loop helps maintain momentum and confidence in code quality. If you’re curious about the setup, it’s all described in LEARNING.md and visible in the repo’s .github/workflows/ scripts!
- jabron 8mo agoSo you read the CI result, implement a fix and stage + commit your changes in ~10 seconds? You might be superhuman.
- whispem 8mo agoI had the opportunity to request a review of my first post (which was flagged) following my email to the moderators of HN. I didn’t use AI for the codebase, only for .md files & there's no problem with that. My project was reviewed by moderators, don't worry. If the codebase or architecture was AI generated this post would not have been authorized and therefore it would not have been published.
- skylurk 8mo agoHow does this deleted fix_everything.sh fit in to your story? https://github.com/whispem/minikv/commit/6e01d29365f345283ec9a2a6c46a36ba77ad060c https://github.com/whispem/minikv/commit/6e01d29365f345283ec...
- rollulus 8mo agoI thought that your “background in literature” contributed to the “well-written docs”, but that was LLMs!
- whispem 8mo agoNo, I was helped (.md files only) by AI to rewrite but the majority of the doc is written by myself, I just asked for help from the AI for formatting for example.
- whispem 8mo agoYes, I do split my working tree into separate commits whenever possible! I use interactive staging (git add -p) to split logical chunks: features, fixes, cleanups, and documentation are committed separately for clarity. Early in the project (lots of exploratory commits), some changes were more monolithic, but as minikv matured, I've prioritized clean commit history to make code review and future changes easier. Always happy to get workflow tips — I want the repo to be easy to follow for contributors!
- ritcgab 7mo agoBut you will never commit them via GitHub's web interface one file at a time :)