I believe this was an oversight. "jj duplicate" should duplicate commits (=
patches), not trees.
This patch adds a separate test file because test_rewrite.rs is pretty big, and
we'll probably want to migrate CLI tests to jj-lib.
The working-copy revision is usually the latest commit, but it's not always
true. This patch ensures that the wc branch is emitted first so the graph node
order is less dependent on rewrites.
If you have multiple remotes to push to, you might want to keep some changes
(such as security patches) in your private fork. Git CLI has one upstream remote
per branch, but jj supports multiple tracking remotes, and therefore "jj git
push" can start tracking new remotes automatically.
This patch makes new bookmarks not eligible for push by default. I considered
adding a warning, but it's not always possible to interrupt the push shortly
after a warning is emitted.
--all implies --allow-new because otherwise it's equivalent to --tracked. It's
also easier to write a conflict rule with --all/--deleted/--tracked than with
two of them.
-c/--change doesn't require --allow-new because it is the flag to create new
tracking bookmark.
#1278
I hope we'll have support for copies and renames in not too long. It's
good to have as many versions before that as possible without support
for `jj move`, in case we want to later use that to record a moved
file (maybe as an alias for `jj file move`).
There are two known limitations right now:
- Only statically known keys are suggested.
- Keys that the user did not set are still suggested for `jj config get`.
Running that suggestion may result in an error. The error message will be
appropriate though and there is some value in letting the user know that
this config value theoretically exists. Some users may try to explore what
configurations are available via the completions.
This is a workaround for command name completion. On zsh, the complete position
is specified by $_CLAP_COMPLETE_INDEX, and an empty argument isn't padded. So,
for "jj <TAB>", { args = ["jj"], index = 1 } is provided, and our expand_args()
helpfully fills in the default command "log". Since args[index] is now "log",
no other commands are listed.
Perhaps it would be nice to point to the revset docs from every
argument that takes a revset, or perhaps that would be too
verbose. `jj log` is perhaps where most people first run into revset
syntax, so I hope pointing to the docs from there is a good start.
This forces us to think about which repo should be used. It doesn't matter in
find_bookmarks_to_push() because moved "push-{change_id}" bookmarks are
prioritized. It doesn't matter in print_commits_ready_to_push() either, which
uses the repo only for ancestry lookup, but I think tx.repo() is better here.
This makes completions suggest aliases from the user or repository
configuration. It's more useful for long aliases that aren't used very often,
but serve the purpose of "executable documentation" of complex and useful jj
commands.
An earlier patch "resolved" aliases, meaning that any arguments following an
alias would be completed as if the normal command had been used. So it only
made sure that using aliases doesn't degrade the rest of the completions.
Commit ID: 325402dc9463ccaa70822069b3e94716d9cc7417
There is now an updated version of `esl01-renderdag` published from
the Sapling repo, so let's use that. That lets us remove the
`bitflags` 1.x dependency and the `itertools` 0.10.x non-dev
dependency.
This commit modifies the commit graph used in the `rebase --after
--before` test case to add an additional branch of commits for use in
tests for `rebase -b` along with `--after --before`.
This commit extracts out the common code printing out the
`MoveCommitsStats` information into a shared function. The printed
output was also inconsistent between `-r` and `-s`/`-b` code paths, so I
standardized it to say "Rebased ? commits onto destination" for both
cases.
The destination commits are selected based on annotation, which I think is
basically the same as "hg absorb" (except for handling of consecutive hunks.)
However, we don't compute a full interleaved delta right now, and the hunks are
merged in the same way as "jj squash". This means absorbed hunks might produce
conflicts if no context lines exist. Still I think this is more intuitive than
selecting destination commits based on patch commutativity.
I've left inline comments to the tests where behavior is different from "hg
absorb", but these aren't exhaustively checked.
Closes#170
The primary use case is to exclude immutable commits when calculating line
ranges to absorb. For example, "jj absorb" will build annotation of @ revision
with domain = mutable().
Unlike other documented aliases, it can be redefined by the user.
However, I think it's important for people to be informed that `b`
exists.
I left `amend`, `unamend`, and `ci` undocumented, since I think we were
considering removing or at least discouraging them.
Previously, attempting to modify an immutable commit only showed the
ID of the commit being modified, which wasn't very helpful when trying
to figure out which immutable commit is being modified at a quick
glance.
This commit prints the commit summary as a hint to make it simpler for
the user to see what the immutable commit is without having to run
`jj show <commit-id>`.
Maybe we can add comparison of ids, commits, etc., but I don't have a practical
use case right now. If we add lt/gt, it might make sense to implement them on
Timestamp type.
I also changed lhs.and_then(..) to (lhs, rhs).map(..) since we don't need
short-circuiting behavior here.
