Hacker News Reader

Comment by edflsafoiewq | Hacker News Reader

Switch to branch for thing 1, work on it, commit, switch to branch for thing 2, work on it, commit, ...

Do you stash or create a commit with potentially partial work? What do you name that commit?

Personally I usually stash if it's partial work I'm going to return to soon. But you can create a commit if you want. Just name it 'WIP' or 'temp' or something. When you come back and finish it you can write the proper commit message.

And then you have to remember which branch the each entry of the stash was on, deal with unstashing conflicts, remember to drop the latest stash after fixing those, etc.

Tools like the stash are band aids that come with their own set of “fun” failure modes.

If you don't like stash, then use WIP commits like I said.

The easiest and by far most common thing to do of course is to just complete the commit you're working on before switching branches.

I have accidentally pushed wip commits more times than I care to remember.

Wouldn’t it be nice if there was a tool that didn’t need you to internalize all these workarounds?

I don't believe I've ever pushed a WIP commit. Count that to the benefits of stashing I guess.

I don't consider any of this a problem, but why don't you tell me how your preferred tool does it.

So when I say there a problems with stashing, you suggest wip commits. When I point out problems with wip commits, we go back to stashing?

jj needs neither because everything in your working copy is already part of a commit. You can’t accidentally push unfinished changes because jj will complain if it hasn’t been described (given a commit message). If you need to move changes between commits you don’t need to stash because you can easily move the contents of a commit around.

Stashing vs WIP commits have pros and cons. I've never hit any of these problems you're pointing out, so I don't have any particular strong opinion about which one you should use.

I can see that being nice I guess.

If jj's stashes are just regular commits, don't you have the problem where you accidentally push a stash just like you push a WIP commit?

It’s not like these are git’s only pain points. Git is practically the poster child for software that’s difficult and confusing to use.

I don't think so. Like the OP, my everyday git usage is pretty straightforward. So "maybe this thing you do every once in a while could be a little nicer" doesn't feel very compelling.

> don't you have the problem where you accidentally push a stash just like you push a WIP commit?

Because jj doesn’t require commits to be on a branch, and the equivalent feature (bookmarks) don’t automatically advance, if you created a new commit to stash some stuff, the name wouldn’t move to it, and so when you push nothing would happen.

Whatever I want because —amend is a thing?

that's fine, what Im saying is that the above workflow is idealized and you have to do a lot more things overtime. If you look at the happy path it looks similar. With the unhappy path instead of keeping stashes and commiting trash then amending. You describe your change beforehand, and any change you do goes there. Thats it. Hotfix? jj new main go back to what you were working on? jj edit refA need to solve some problems in another pr of youre? jj edit refB.

Theres no overhead at all in thinking these, you can never lose work by mistake, you can never mess it up. It just works

`git add .`, `git commit -m "wip: some note about what I was doing"

Then checkout the new branch and do my work.

When I come back, `git reset --soft HEAD^`, and continue

Your comment is a great ad for not using git.

Now let’s talk rebase/merge conflicts, stash conflicts, forgetting to un-wip, and on and on and on and then maybe acknowledge that all of these “but my git workflow is simple” comments are a convenient fiction that doesn’t actually exist in practice.

Reply on news.ycombinator.com