Hacker News Reader

Comment by brundolf | Hacker News Reader

I make a point never to commit broken code anyway. If a series of changes have to be together to not break, I put them all in one commit. And for organization’s sake, commits could still be tagged by ticket

That doesn't mean an entire feature has to go in one commit (usually). Often a feature is made up of a series of non-breaking changes that can be layered one at a time, if appropriate.

View on HN

As a reviewer I really want a series of commits each making closely related changes that are easy to understand. Squashing tends to make giant diffs that replace almost every line, and you almost have to reverse-engineer to figure out what’s actually supposed to be different.

How about with multiple repos, across multiple systems? Eg. embedded device with 4-week test cycles, backend server with CI/CD, frontend site with CI/CD, and upstream vendor contribution PR(s), and where the data fees for firmware updates to the set of all customer embedded devices run into the hundreds of thousands of dollars? You can't get them all in one commit then. Even with a monorepo (not contributing back to upstream) it'd be an utterly massive commit.

That negates one of the major advantages of committing code, which is having a regular backup of your work.

My team makes several commits locally, then rebases, squashes, and pushes the squashed commit to the trunk which has CI. This maintains a local, regular backup of your code and collects features into single commits for the trunk which are easily revertable if found to be problematic. This flow will not work for everyone, but it works very well for us (a team of 8 at a FAANG company).

Edit: Rereading your comment, I suspect you mean non-local backups. Our organization has a special remote only visible to you and those you allow for pushing code you'd like to backup off of your box.

That sounds like feature branches but with more steps and worse. You can't share your unfinished work non-locally, for one thing. And it has none of the advantages of CI because you still have infrequent large merges.

> If a series of changes have to be together to not break, I put them all in one commit.

I'm sorry but it hurts just to read this. Just No.

Please could you expand? Without substance, there’s nothing here that defends your position.

Going back through history to find where a bug was introduced usually happens on the commit level (e.g. git-bisect only operates on commits, naturally). Once you find the commit that introduced the bug in question, it will be immensely easier to hunt down the bug within the commit if the commit is 10 or 50 lines long instead of 500 or 1000.

Reply on news.ycombinator.com