Hacker News Reader

Comment by embedding-shape | Hacker News Reader

> The first commit was 17k lines. So this was either developed without using version control or at least without using this gh repo.

Most of my free-time projects are developed either by my shooting the shit with code on disk for a couple of months, until it's in a working state, then I make one first commit. Alternatively, I commit a bunch iteratively, but before making it public I fold it all into one commit, which would be the init. 20K lines in the initial commit is not that uncommon, depends a lot on the type of project though.

I'm sure I'm not alone with this sort of workflow(s).

View on HN

Can you explain the philosophy behind this? Why do this, what is the advantage? Genuinely asking, as I'm not a programmer by profession. I commit often irrespective of the state of the code (it may not even compile). I understand git commit as a snapshot system. I don't expect each commit to be pristine, working version.

Lot of people in this thread have argued for squashing but I don't see why one would do that for a personal project. In large scale open source or corporate projects I can imagine they would like to have clean commit histories but why for a personal project?

> I don't expect each commit to be pristine, working version.

I guess this is the difference, I expect the commit to represent a somewhat working version, at least when it's in upstream, locally it doesn't matter that much.

> Why do this, what is the advantage?

Cleaner I suppose. Doesn't make sense to have 10 commits whereas 9 are broken half-finished, and 10 is the only one that works, then I'd just rather have one larger commit.

> they would like to have clean commit histories but why for a personal project?

Not sure why it'd matter if it's personal, open source, corporate or anything else, I want my git log clean so I can do `git log --short` and actually understand what I'm seeing. If there is 4-5 commits with "WIP almost working" between each proper commit, then that's too much noise for me, personally.

But this isn't something I'm dictating everyone to follow, just my personal preference after all.

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.

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

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.

> I guess this is the difference, I expect the commit to represent a somewhat working version,

On a solo project I do the opposite: I make sure there is an error where I stopped last. Typically I put in in a call to the function that is needed next so i get a linker error.

6 months later when I go back to the project that link error tells me all I need to know about what comes next

How does that work out if you want to use `git bisect` to find regressions or similar things?

I dont do bisects on each individual branch. I'll bisect on master instead and find the offending merge.

From that point bisect is not needed.

> If there is 4-5 commits with "WIP almost working" between each proper commit, then that's too much noise for me, personally.

Yep, no excuse for this, feature branches exist for this very reason. wip commits -> git rebase -i master -> profit

I do that because there's no point in anyone seeing the pre-release versions of my projects. They're a random mess that changed the architecture 3 times. Looking at that would not give anyone useful information about the actual app. It doesn't even give me any information. It's just useless noise, do it's less confusing if it's not public.

I don't care about anyone seeing or not seeing my unfinished hobby projects, I just immediately push to GitHub as another form of backup.

you should push to a private working branch- and freqently. But, when merging your changes to a central branch you should squash all the intermediate commits and just provide one commit with the asked for change.

Enshrining "end of day commits", "oh, that didn't work" mistakes, etc is not only demoralizing for the developer(s), but it makes tracing changes all but impossible.

Yeah, I don't care about that for my tiny hobby projects which are used by no one. XD

I don't care about backing up unfinished hobby projects, I just write/test until arbitrarily sharing, or if I'm completely honest, potentially abandoning it. I may not 'git init' for months, let alone make any commits or push to any remotes.

Reasoning: skip SCM 'cost' by not making commits I'd squash and ignore, anyway. The project lifetime and iteration loop are both short enough that I don't need history, bisection, or redundancy. Yet.

Point being... priorities vary. Not to make a judgement here, I just don't think the number of commits makes for a very good LLM purity test.

I literally keep this in my bash history so i can press up once and hit enter to commit: `git add *; git commit -m "changes"; git push origin main;`

I use git as backup and commit like every half an hour... but make sure to give proper commit message once a certain milestone have been reached.

Im also with the author on this on squashing all these commits into a new commit and then pushing it in one go as init commit before going public.

Reply on news.ycombinator.com