mirror of
https://github.com/martinvonz/jj.git
synced 2025-05-06 07:52:50 +00:00
130 lines
5.7 KiB
Markdown
130 lines
5.7 KiB
Markdown
# 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][gitignore].
|
|
|
|
### 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:
|
|
|
|
```shell script
|
|
# 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`.
|
|
|
|
[config]: ./config.md
|
|
|
|
[gitignore]: https://git-scm.com/docs/gitignore
|
|
|
|
[revsets]: ./revsets.md
|
|
|
|
[templates]: ./templates.md
|
|
|
|
[this issue]: https://github.com/martinvonz/jj/issues/1531
|