5 ms·

I also use this as a simple heuristic: https://github.com/nkuntz1934/matrix-workers/commits/main/ https://github.com/nkuntz1934/matrix-workers/commits/main/ T

by bob1029 9mo ago

I also use this as a simple heuristic: https://github.com/nkuntz1934/matrix-workers/commits/main/ https://github.com/nkuntz1934/matrix-workers/commits/main/ There exist only two commits. I've never seen a "real" project that looks like this.

biohazard2 9mo ago
The repository is less than one week old though; having only the initial commit wouldn't shock me right away.
- jstanley 9mo ago
  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.
  - btown 9mo ago
    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 :)
- cortesoft 9mo ago
  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.
  - deleted 9mo ago
    [deleted]
victorbjorklund 9mo ago
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.
- masklinn 9mo ago
  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”.
InsideOutSanta 9mo ago
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.
- ectospheno 9mo ago
  I have a similar process. Internal repo where work gets done. External repo that only gets each release.
Hamuko 9mo ago
I might just make dummy commits ("asdadasdassadas") in the prototyping phase and then just squash everything to an "Initial commit" afterwards.
subscribed 9mo ago
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 :)

by bob1029 9mo ago

biohazard2 9mo ago

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

jstanley 9mo ago
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.
- btown 9mo ago
  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 :)
cortesoft 9mo ago
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.
- deleted 9mo ago
  [deleted]

victorbjorklund 9mo ago

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.

masklinn 9mo ago
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”.

InsideOutSanta 9mo ago

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.

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

Hamuko 9mo ago

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

subscribed 9mo ago

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 :)