Hacker News Reader

Comment by jadar | Hacker News Reader

I tend to just commit whenever I see fit, then at the end I do a `git reset —soft` and write the history that makes sense before pushing.

View on HN

I always tell people I use a “git reset” based workflow. I rarely “checkout” branches, I just stay on main, reset hard when switching topics, reset soft when squashing, and I only name my branches on the remote end via “git push origin HEAD:some-branch”.

`git branch` is basically my bookmark tool. I commit for a while, then when I want to remember where I am for later, `git branch wip/topic-a-finally-compiles` or whatever. I can reset hard to it when I want to revert back, or any other topic I need. If I forget to name a branch for a commit, the reflog is right there. Nothing’s lost.

And yeah, a soft reset is basically the ideal way to just say “pretend all my changes weren’t committed yet, starting from $ref” and then I make my single commit for my PR. Easy peasy.

I follow something similar, especially with the PR process and squash-merge on remote. I do the first ticket push using explicit ref, then just continue on the next one, while I wait for the review process. When the first PR is merged, I rebase on top of the remote branch and do the same for the second PR.

I do switch branch for long experiments and touch up on existing PR.

It would be great if a PR was about distributing patches and not having those automatically generated from a branch.

I can’t tell if this is satire. The fact that we have to memorize soft and hard resets was a thing I and everyone else just have to do. But that goes away if you only have commits, so no staging area vs staged changes vs changes on disk, it’s just all a commit and we have a myriad of tools that already know how to deal with commits. Honestly, your workflow as described sounds incredibly compatible with jujutsu, I’d really recommend giving it a shot / another go

Reply on news.ycombinator.com