4 ms·
I interpreted the parents post as: as long as my combination of commits results in something working before getting merged, it's fine. Local wip commits didn't
by hbogert 10mo ago
I interpreted the parents post as: as long as my combination of commits results in something working before getting merged, it's fine.
Local wip commits didn't come to mind at all
- bawolff 10mo agoWell we are in a discussion about pre-commit hooks. Pre-commit hooks run on local wip commits.
- thomashabets2 10mo agoWell, unless you inhibit them with `-n`. Which I would for WIP commits.
- badgersnake 10mo agoThen what’s the point? Just leave them off and run the tests when you want to run them.
- thomashabets2 10mo agoBecause 99% of my commits are not WIP commits. So I almost always want to run them. Hell, even most WIP commits will pass the tests (e.g. tests are not yet added for the new code), so I'd run them then too.
- normie3000 10mo agoSome people write tests first.
- thomashabets2 10mo agoAnd commit in such that the final timeline has broken tests for half of commits? Sounds like an awful way to live your life.
- normie3000 10mo agoNo, we're not talking about the final timeline. That is finalised when (or if) code is merged to the mainline. We're talking about what happens when the command "git commit" is executed.
- thomashabets2 10mo agoOk, if you're talking about just WIP commits that will be squashed and will never be part of mainline, then shrug. For me that's a tiny proportion of commits. I'd rather avoid taking a whole finished feature branch and then spend more time cleaning up a sloppy commit history. Sure, sometimes it's correct to squash, but for nontrivial changes I go with https://github.com/google/eng-practices/blob/master/review/developer/small-cls.md https://github.com/google/eng-practices/blob/master/review/d...