[forgotpwd16]

>All the code, architecture, logic, and design in minikv were written by me, 100% by hand.

Why people always lie with this? Especially in this case that they uploaded the entire log:

  Date:   Sat Dec 6 16:08:04 2025 +0100
      Add hashing utilities and consistent hash ring
  Date:   Sat Dec 6 16:07:24 2025 +0100
      Create mod.rs for common utilities in minikv
  Date:   Sat Dec 6 16:07:03 2025 +0100
      Add configuration structures for minikv components
  Date:   Sat Dec 6 16:06:26 2025 +0100
      Add error types and conversion methods for minikv
  Date:   Sat Dec 6 16:05:45 2025 +0100
      Add main module for minikv key-value store

And this goes on until project is complete (which probably took 2~3h total if sum all sessions). Doubt learned anything at all. Well, other than that LLMs can solo complete simple projects.

Comments in previous submission are also obviously AI generated. No wonder was flagged.

[yes_man]

You have never split your working tree changes into separate commits?

[forgotpwd16]

Irrelevant 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/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.

[whispem]

Yes, 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]

But you will never commit them via GitHub's web interface one file at a time :)

[kryptiskt]

It looks like that if you want logically separated commits from a chunk of programming you have done. Stage a file or a hunk or two, write commit message, commit, rinse and repeat.

[whispem]

Absolutely: for all meaningful work I prefer small, logical commits using git add -p or similar, both for history clarity and for reviewer sanity. In initial “spike” or hack sessions (see early commits :)), it’s sometimes more monolithic, but as the codebase stabilized I refactored to have tidy, atomic commit granularity. I welcome suggestions on workflow or PR polish!