[n4r9]

> You don’t need to explicitly tell jj about what you’ve done in your working copy, it’s already tracked. This removes the need for an “index” or staging area

Does this mean that you have to proactively remember and undo any config file changes you made e.g. while fixing an issue in a test environment? Sounds a little risky.

[MrJohz]

As others have pointed out, gitignore exists and you should try and build your configuration so that most of the time you're changing gitignored files rather than checked in ones. That said, you can do some pretty cool stuff with Jujutsu in this regard. Because changes are always automatically rebased, you can often create the change that will ultimately become your final commit, then create a new change where you edit any config you need to, then a change on top of that that's basically your staging area.

For example, I recently had a set up that looked something like this:

    @ w - the checked out change where I'm editing files
    |
    * x - local config change
    |
    * y (bookmark 1) - CI config change that sets up a temp test env
    |
    * z (bookmark 2) - Start of the changes that will eventually get reviewed and merged

With this set up, I could make changes in an environment that included all of the config changes I needed. Then when I was happy with something and wanted to "save my work", I could run `jj squash --to z`, which would squash everything in change w into change z, rebasing everything else automatically on top of that. Then I could run `jj git push`, and this force-pushed the changes at y and z to their separate branches on GitHub. I had a pull request for the branch at z which other people could then review and where all the tests could run. Meanwhile the branch at y had updated the CI config to remove the usual tests and deploy everything to a temporary environment. So each push automatically updated my test env, and updated the pull request with the "clean" changes (i.e. without my config file fiddling).

If I wanted this sort of setup more long term, I'd find some other way to achieve it without relying on Jujutsu, but for ad-hoc cases like this it's absolutely great.

[ramon156]

Agreed, and these comments fail to remember you sometimes need code changes to debug. Its nice to stage/unstage code changes, and gitignore won't help u there

[n4r9]

Exactly. 'git add' forces you to locally review which code changes you actually need, and catch any debug code, attempted fixes, a bit of whitespace you typed while thinking, refactorings that didn't actually turn out to help etc... . Otherwise it's up to the reviewer to spot.

[arccy]

some of us do `git add .`, you can't ship an unbuildable commit because you forgot something

what you should have is support for local, gitignore-able config files