logoalt Hacker News

gertburgertoday at 7:30 AM7 repliesview on HN

I'd like to give jj another go but I found the "all files must be tracked/committed" approach to really break my workflow. I have a lot of temporary uncommitted files, which are not ignored or excluded. Some may eventually be committed but most won't. Being then forced to commit these (but only some due to file size) just gets in the way and impedes things like cross branch debugging

A checkout is a working space after all, why can't it be (temporarily) dirty whilst you work?


Replies

jezzamontoday at 2:39 PM

If you do want to solve this, here's two thoughts on how you can deal with it. First: don't try to edit jj changes. Always work on a new change and then squash that in to the parent. You think of that top level change as your working space.

From there, the simplest way is to just always use 'jj commit -i' and 'jj squash -i' to create change ids with your work. Then if you want to have your changes move around with you, just rebase your working copy which contains your "uncommitted files" to the new branch.

A different idea is to put those changes in a separate change, and then when you do work, always create your working space change as a merge change like 'jj new <uncommitted file change id> <main change id>. Then you should be able to do 'jj absorb' instead of 'jj squash' to put changes into the right change. Switching to a different branch is 'jj new <uncommitted file change id> <other change id>.

As in typing this, I'm thinking for myself and what I actually do in practice... I find moving / rebasing jj commits very easy (I have a UI tool that literally lets you drag and drop them) so I usually just commit these changes and then drag the commits around so it's not in the chain of when I want to send it out for review

maleldiltoday at 9:29 AM

Why not add them to gitignore? If you don't want to change the project's ignore, there's also a repository local ignore file, .git/info/exclude, which jj will respect.

> why can't it be (temporarily) dirty whilst you work?

Because that would go completely against how jj changes work.

silon42today at 10:20 AM

Same here, auto-adding is a non-starter for me. Thankfully there's an option to not do it, not sure how well it works, but I'll have it enabled for the future when I try jj again.

JimDabelltoday at 10:41 AM

When you are ready to record a change, split your current working changeset and pick the things you want to commit. It’s equivalent to staging then committing with Git.

arccytoday at 10:29 AM

auto add is nice for universal undo for changes made outside your editor...

instead of adding changes to a new commit, i split/squash them into the previous one so the current commit remains dirty

a10ctoday at 8:39 AM

[flagged]