4 ms·

Yep, all that and they’re also annoying. Version control tools are not supposed to argue - do what you’re told. If I messed up, the branch build will tell me.

thomashabets2 10mo ago
Is that the difference between forced pre commits vs opt in? I don't want to commit something that doesn't build. If nothing else it makes future bisects annoying. But if I intend to squash and merge, then who cares about intermediate state.
- normie3000 10mo ago
  > I don't want to commit something that doesn't build. This is a really interesting perspective. Personally I commit code that will fail the build multiple times per day. I only care that something builds at the point it gets merged to master.
  - hbogert 10mo ago
    so basically, not adhering to atomic commits. That's fine if it's a deliberate choice, but some people like me think commits should stand on their own. (i'm assuming your are not squashing when merging, else it's pretty much the same workflow)
    - bawolff 10mo ago
      Honestly, i find that a really weird view. I use (Local) commits for work in progress. I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git. What do you do when you are working on something and are forced to switch to working on something else in the middle of it?
      - thomashabets2 10mo ago
        I'm merely the grandparent commenter, not the one you replied to directly, but I can tell you what I do for checkpointing some exploratory work or "I'll continue this next week". I usually put it on a branch, even if this project otherwise does all its development on the main branch. And I commit it without running precommits, and with a commit message prefix "WIP: ". If it's on a branch you can even push it to not lose work if your local machine breaks/is stolen. When it's time to get it into the main branch I rebase to squash commits into working ones. Now, if my final commit history of say 3 commits all actually build at each commit? For personal projects, no. Diminishing returns. But in a collaborative environment: How fun will it be for future you, or your team mates, to run bisect if half the commits don't even build? I have this workflow because it's so easy to add a feature, breaking 3 tests, to be fixed later. And formatting is bad. And now I add another change, and I just keep digging and one can end up in a "oh no, how did I end up here?" state where different binaries in the tree need to be synced to different commits to even build. > I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git. WIP commits is hardly the only benefit of git or other DVCS over things like subversion.
      - 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 ago
        Well we are in a discussion about pre-commit hooks. Pre-commit hooks run on local wip commits.
        thomashabets2 10mo ago
        Well, unless you inhibit them with `-n`. Which I would for WIP commits.
        10mo ago
    - normie3000 10mo ago
      > i'm assuming your are not squashing when merging, else it's pretty much the same workflow I AM squashing before merging. Pre-commit hooks run on any commit on any branch, AFAIK. In any serious repo I'd never be committing to master directly.
OJFord 10mo ago
The first step of which I usually have as pre-commit run --all-files (using the third-party tool of the same name as git feature) - so running locally automatically on changed files just gives me an early warning. It can be nice to run unit tests locally too, btw.

thomashabets2 10mo ago

Is that the difference between forced pre commits vs opt in? I don't want to commit something that doesn't build. If nothing else it makes future bisects annoying. But if I intend to squash and merge, then who cares about intermediate state.

normie3000 10mo ago
> I don't want to commit something that doesn't build. This is a really interesting perspective. Personally I commit code that will fail the build multiple times per day. I only care that something builds at the point it gets merged to master.
- hbogert 10mo ago
  so basically, not adhering to atomic commits. That's fine if it's a deliberate choice, but some people like me think commits should stand on their own. (i'm assuming your are not squashing when merging, else it's pretty much the same workflow)
  - bawolff 10mo ago
    Honestly, i find that a really weird view. I use (Local) commits for work in progress. I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git. What do you do when you are working on something and are forced to switch to working on something else in the middle of it?
    - thomashabets2 10mo ago
      I'm merely the grandparent commenter, not the one you replied to directly, but I can tell you what I do for checkpointing some exploratory work or "I'll continue this next week". I usually put it on a branch, even if this project otherwise does all its development on the main branch. And I commit it without running precommits, and with a commit message prefix "WIP: ". If it's on a branch you can even push it to not lose work if your local machine breaks/is stolen. When it's time to get it into the main branch I rebase to squash commits into working ones. Now, if my final commit history of say 3 commits all actually build at each commit? For personal projects, no. Diminishing returns. But in a collaborative environment: How fun will it be for future you, or your team mates, to run bisect if half the commits don't even build? I have this workflow because it's so easy to add a feature, breaking 3 tests, to be fixed later. And formatting is bad. And now I add another change, and I just keep digging and one can end up in a "oh no, how did I end up here?" state where different binaries in the tree need to be synced to different commits to even build. > I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git. WIP commits is hardly the only benefit of git or other DVCS over things like subversion.
    - 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 ago
        Well we are in a discussion about pre-commit hooks. Pre-commit hooks run on local wip commits.
        thomashabets2 10mo ago
        Well, unless you inhibit them with `-n`. Which I would for WIP commits.
        10mo ago
  - normie3000 10mo ago
    > i'm assuming your are not squashing when merging, else it's pretty much the same workflow I AM squashing before merging. Pre-commit hooks run on any commit on any branch, AFAIK. In any serious repo I'd never be committing to master directly.

OJFord 10mo ago

The first step of which I usually have as pre-commit run --all-files (using the third-party tool of the same name as git feature) - so running locally automatically on changed files just gives me an early warning. It can be nice to run unit tests locally too, btw.