← Back to context

Comment by hbogert

9 hours 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)

8 comments

hbogert

Reply
normie3000  6 hours 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.

bawolff  8 hours 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  8 hours 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.

  • NekkoDroid  7 hours ago

    > 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?

    `git stash` is always an option :) but even if you want to commit it, you can always undo (or `--amend`) the commit when you get back to working. I personally am also a big fan of `git rebase -i` and all the things it allows me to fix up in the history before merging (rebasing) in to the main branch.

  • hbogert  8 hours 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