News for hackers. Stuff that matters.

A comment on SQLite Doesn't Use Git. Parent comment

Re:SQLite Doesn't Use Git by int_19h on Monday September 12, 2022 @03:16PM (#32815351)
It really depends on how you choose to define the granularity. I prefer my commits to all be buildable at least, and ideally also pass the tests (so new code + new tests for it should be in the same commit); but that is subjective and there are valid arguments for smaller commits that are not necessarily isolated like that.

I can't think of any special tools you'd need for this? A git history visualizer with the ability to easily diff and squash ranges helps, but this is nothing special for pretty much any modern IDE. At the end of the day, you just look through the WIP branch history and identify chunks that span multiple commits but logically represent a single change towards some goal.

[ Parent | on HN ]
Re:SQLite Doesn't Use Git by RockingGoodNite on Monday September 12, 2022 @06:13PM (#32817755)
"I prefer my commits to all be buildable at least, and ideally also pass the tests (so new code + new tests for it should be in the same commit); but that is subjective"

In my view, it is not subjective. All commits locally must pass unit, integration and e2e tests, and be locally tested by the developer, every...single...one.

[ Parent | on HN ]
Re:SQLite Doesn't Use Git by sanitycheck on Tuesday September 13, 2022 @04:37AM (#32821925)
Right, OK - pretty manual then. I was envisaging some sort of n-way diffing tool which simulates several staging areas and changes could be moved around line by line, maybe a button to run a build + tests for each in parallel. Gets difficult as soon as code in one of the middle commits needs a bit of extra tweaking to work though, I suppose.

I'll have to try it sometime, I have a feeling it wouldn't normally turn out too differently to what I end up with anyway. I do think all commits should build and run properly - otherwise git bisect and similar processes stop being useful.

[ Parent | on HN ]