[cranium]

Commit even as a WIP before cleaning up! I don't really like polluting the commit history like that but with some interactive rebase it can be as if the WIP version never existed.

(Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)

[SketchySeaBeast]

Assuming you squash when you merge the PR (and if you don't, why not?), why even care? Do people actually look through the commit history to review a PR? When I review I'm just looking at the finished product.

[RandallBrown]

I don't typically review commit by commit, but I do really appreciate having good commit messages when I look at the blame later on while reading code.

[globular-toast]

Indiscriminate squashing sucks. Atomic commits are great if you want the git history to actually represent a logical changelog for a project, as opposed to a pointless literal keylog of what changes each developer made and when. It will help you if you need to bisect a regression later. It sucks if you bisect and find the change happened in some enormous incohesive commit. Squashing should be done carefully to reform WIP and fix type commits into proper commits that are ready for sharing.

[regularjack]

It is often easier to review commit-by-commit, provided of course that the developer made atomic commits that make sense on their own.

[globular-toast]

Git is a distributed version control system. You can do whatever you like locally and it won't "pollute" anything. Just don't merge that stuff into shared branches.

I automatically commit every time my editor (emacs) saves a file and I've been doing this for years (magit-wip). Nobody should be afraid of doing this!

[throwaway-18]

Honest question - What DO you merge into shared branches? And, when your local needs to "catch up", don't you have to pull in those shared commits which conflict with your magit-wip commits because they touch the same code, but are different commit hashes?

[thanksgiving]

Exactly this. I can make a hundred commits that are one file per commit and I can later go back and

    git reset --soft HEAD~100 

and that will cleanly leave it as the hundred commits never happened.

[hiccuphippo]

I assume Jujutsu only commits the file when you use one of the jj commands. I don't think it keeps a daemon running and checking for changes in the files.

[steveklabnik]

It does the former by default, and the latter if you configure it.

[steveklabnik]

> (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)

Yes! For the case discussed in the article, I actually just wrote a comment yesterday on lobsters about the 'evolog': https://lobste.rs/s/xmlpu8/saving_my_commit_with_jj_evolog#c...

Basically, jj will give you a checkpoint every time you run a jj command, or if you set up file watching, every time a file changes. This means you could recover this sort of thing, assuming you'd either run a commend in the meantime or had turned that on.

Beyond that, it is true in my experience that jj makes it super easy to commit early, commit often, and clean things up afterwards, so even though I was a fan of doing that in git, I do it even more with jj.

[bayindirh]

I always commit when wrapping up the day. I add [WIP] in the subject, and add "NOTE: This commit doesn't build" if it's in a very half-baked state.

[SketchySeaBeast]

I do a bunch of context switching, and I commit every time I switch as stashing would be miserable. I never expect those WIP commits to reviewed and it'd be madness to try.

[elSidCampeador]

same - my eod commits are always titled 'checkpoint commit: <whatever>' and push to remote. Then before the MR is made (or turned from draft to final) I squash the checkpoint commits - gives me a psychological feeling of safety more than anything else imo