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

To me it is most important that the commit is focused only on one thing, and not mix any unrelated changes together.

We develop a Rust based tool HighFlux [1] which simplifies/automates working with git. In this workflow you create a feature branch for every feature you work on and it automatically commits all changes to this branch. After code review the branch gets merged as a squashed merge to have it in a single commit in the history.

1: https://www.highflux.io/



How do you keep you commit focused on one thing if you squash?

Often, before you reach to the point where you can make the change you want, you need to make side-changes which are not a strict part of the feature you're building.

These should ideally be reviewed separately.


I agree this happens quite often. Since Highflux automatically commits changes to the current branch it is extremely easy to switch to a different branch with just one click (or CLI command). (so no stashing / dealing with untracked files is needed) Then you can implement the side change separately and then switch back again to your first feature branch.

Those two feature branches are then unrelated, we are planning to add stacked changes in a future version.


There had to be a rust ad in here somewhere.


The ad is about a git tool (hiflux) that happens to be written in Rust. That is perfectly relevant in this context. Rust is also a good language to write such tools (as is Go). I understand why Rust evangelism can be a bit tiring. But the opposition to it shouldn't try to imitate the same quality.




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

Search: