jj/docs/FAQ.md

Frequently asked questions

Why does my branch not move to the new commit after jj new/commit?

If you're familiar with Git, you might expect the current branch to move forward when you commit. However, Jujutsu does not have a concept of a "current branch".

To move branches, use jj branch set.

I made a commit and jj git push --all says "Nothing changed" instead of pushing it. What do I do?

jj git push --all pushes all branches, not all revisions. You have two options:

• Using jj git push --change will automatically create a branch and push it.
• Using jj branch commands to create or move a branch to either the commit you want to push or a descendant on it. Unlike Git, Jujutsu doesn't do this automatically (see previous question).

Where is my commit, why is it not visible in jj log?

Is your commit visible with jj log -r 'all()'?

If yes, you should be aware that jj log only shows the revisions matching revsets.log by default. You can change it as described in config to show more revisions.

If not, the revision may have been abandoned (e.g. because you used jj abandon, or because it's an obsolete version that's been rewritten with jj rebase, jj describe, etc). In that case, jj log -r commit_id should show the revision as "hidden". jj new commit_id should make the revision visible again.

See revsets and templates for further guidance.

Can I prevent Jujutsu from recording my unfinished work? I'm not ready to commit it.

Jujutsu automatically records new files in the current working-copy commit and doesn't provide a way to prevent that.

However, you can easily record intermediate drafts of your work. If you think you might want to go back to the current state of the working-copy commit, simply use jj new. There's no need for the commit to be "finished" or even have a description.

Then future edits will go into a new working-copy commit on top of the now former working-copy commit. Whenever you are happy with another set of edits, use jj squash to amend the previous commit.

For more options see the next question.

Can I add a portion of the edits I made to a file, similarly to git add -p or hg commit -i?

At the moment the best options to partially add a file are: jj split, jj amend -i and jj move -i.

Is there something like git rebase --interactive or hg histedit?

Not yet, you can check this issue for updates.

To reorder commits, it is for now recommended to rebase commits individually, which may require multiple invocations of jj rebase -r or jj rebase -s.

To squash or split commits, use jj squash and jj split.

How can I keep my scratch files in the repository?

You can keep your notes and other scratch files in the repository, if you add a wildcard pattern to either the repo's gitignore or your global gitignore. Something like *.scratch or *.scratchpad should do, after that rename the files you want to keep around to match the pattern.

If $EDITOR integration is important, something like scratchpad.* may be more helpful, as you can keep the filename extension intact (it matches scratchpad.md, scratchpad.rs and more).

You can find more details on gitignore files here.

How can I keep local changes around, but not use them for Pull Requests?

In general, you should separate out the changes to their own commit (using e.g. jj split). After that, one possible workflow is to rebase your pending PRs on top of the commit with the local changes. Then, just before pushing to a remote, use jj rebase -s child_of_commit_with_local_changes -d main to move the PRs back on top of main.

If you have several PRs, you can try jj rebase -s all:commit_with_local_changes+ -d main (note the +) to move them all at once.

An alternative workflow would be to rebase the commit with local changes on top of the PR you're working on and then do jj new commit_with_local_changes. You'll then need to use jj new --before to create new commits and jj move --to to move new changes into the correct commits.

How do I resolve conflicts after rebasing a stack of revisions changing a file on top of a revision renaming that file?

Currently, jj does not understand renames (https://github.com/martinvonz/jj/issues/47) and interprets them as a deletion of one file and the creation of another file. So, rebasing on top of a revision that renames a file results in "edit-deletion" conflicts.

At the moment, there is no perfect workaround. Generally, it helps to rebase on top of the revision just before the file gets renamed first, resolve any conflicts, and finally apply one of the following workarounds to rebase it on top of the revision that moves the file.

One option to resolve the edit-deletion conflict is to jj restore path_to_file_with_conflict ... TODO

In a colocated repo, another option is to use git rebase, which usually does a good job of recognizing renames. This is done as follows:

# Mark the revision we're rebasing *onto* with a branch
jj branch c target -r revision_that_moves_the_file
# Make sure the working copy is clean before using git commands
jj new
git switch branch_on_top_of_the_stack_to_rebase
git rebase target

In many, especially if you followed the above general advice, this should immediately succeed and you are done.

If there are any merge conflicts, make sure to only use git commands until the conflicts are resolved and git status looks clean. You can also give up at this point by using git rebase --abort.