top | item 47059809

(no title)

kmaitreys | 11 days ago

Fair enough. Thanks for the clarification. Personally, I think, everything before a versioned release (even something like 0.1) can be messy. But from your point I can see it that a cleaner history will have advantages.

Further, I guess if author is expecting contributions to the code in the future, it might be more "professional" for the commits to only the ones which are relevant.

My own projects, I consider, are just for my own learning and understanding so I never cared about this, but I do see the point now.

Regardless, I think it still remains a reasonable sign of someone doing one-shot agent-driven code generation.

discuss

order

embedding-shape|11 days ago

One point I missed, that might be the most important, since I don't care about it looking "professional" or not, only care about how useful and usable something is: if you have commits with the codebase being in a broken state, then `git bisect` becomes essentially useless (or very cumbersome to use), which will make it kind of tricky to track down regressions unless you'd like to go back to the manual way of tracking those down.

> Regardless, I think it still remains a reasonable sign of someone doing one-shot agent-driven code generation.

Yeah, why change your perception in the face of new evidence? :)

kmaitreys|11 days ago

I see the point.

Regarding changing the perception, I think you did not understand the underlying distrust. I will try to use your examples.

It's a moderate size project. There are two scenarios: author used git/some VCS or they did not use it. If they did not use it, that's quite weird, but maybe fine. If they did use git, then perhaps they squashed commits. But at certain point they did exist. Let's assume all these commits were pristine. It's 16K loc, so there must be decent number of these pristine commits that were squashed. But what was the harm in leaving them?

So these commits must have been made of both clean commits as well as broken commits. But we have seem this author likes to squash commits. Hmm, so why didn't they do it before and only towards the end?

Yes, I have been introduced to a new perception but it's the world does not work "if X, then not Y principles." And this is a case where the two things being discussed are not mutually exclusive like you are assuming. But I appreciate this conversation because I learnt importance and advantages of keeping clean commit history and I will take that into account next time reaching to the conclusion that it's just another one-shot LLM generated project. But nevertheless, I will always consider the latter as a reasonable possibility.

I hope the nuance is clear.