Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wonder by your last comment if this is just is talking past each other.

I try very hard to keep my PRs very focused on one complete unit of work at a time. So when the squash happens that single commit represents one type of change being made to the system.

So when going through history to pinpoint the cause of the big, I can still get what logical change and unit of work caused the change. I don't see the intermediary commits of that unit of work, but I have not personally gotten value out of that level of granularity (especially on team projects where each person's commit practices are different).

If I start working on one PR that starts to contain a refactor or change imthat makes sense to isolate, I'll make that it's own pr that will be squashed.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: