Hacker News Reader

Comment by bob1029 | Hacker News Reader

I also use this as a simple heuristic:

https://github.com/nkuntz1934/matrix-workers/commits/main/

There exist only two commits. I've never seen a "real" project that looks like this.

To be honest sometimes on my hobby project I don’t commit anything in the beginning (I know not great strategy) and then just dump everything in one large commit.

I’ve also been guilty of plugging at something, and squashing it all before publishing for the first time because I look at the log and I go “no way I can release this, or untangle it into any sort of usefulness”.

I think that's a reasonable heuristic, but I have projects where I primarily commit to an internal Gitea instance, and then sometimes commit to a public GitHub repo. I don't want people to see me stumbling around in my own code until I think it's somewhat clean.

I have a similar process. Internal repo where work gets done. External repo that only gets each release.

The repository is less than one week old though; having only the initial commit wouldn't shock me right away.

But if the initial commit contains the finished project then that suggests that either it was developed without version control, or that the history has deliberately been hidden.

It was/is quite common for corporate projects that become open-source to be born as part of an internal repository/monorepo, and when the decision is made to make them open-source, the initial open source commit is just a dump of the files in a snapshotted public-ready state, rather than tracking the internal-repo history (which, even with tooling to rebase partial history, would be immensely harder to audit that internal information wasn't improperly released).

So I wouldn't use the single-commit as a signal indicating AI-generated code. In this case, there are plenty of other signals that this was AI-generated code :)

That is totally fine... as long as you don't call it 'production grade'. I wouldn't call anything production grade that hasn't actually spent time (more than a week!) in actual production.

I usually work in branches in a private repo, squash and merge features / fixes in the private repo, and only merge the clean, verified, extensively tested merges back to public.

You don't need to see every single commit and the exact chronology of my work, snapshots is enough :)

I might just make dummy commits ("asdadasdassadas") in the prototyping phase and then just squash everything to an "Initial commit" afterwards.

Reply on news.ycombinator.com