I'm thinking of adding an option to embed operation diffs in "op log", and
"op log" shouldn't fail at the root operation. Let's make "op diff"/"show"
also work for consistency.
This flag implements three modes:
- `copy`: copy sparse patterns from parent
- `full`: do not copy sparse patterns from parent
- `empty`: clear all paths, equal to `set --clear`
This is useful for various tooling like tools that want to run a parallel
process that queries the build system (without running into locks/blocking.)
I think continuing to copy sparse patterns makes sense as the default behavior.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This enables workflows like "insert a commit that reformats the code in one of
my project directories".
`jj fix --include-unchanged-files` is an easy way to fix everything in the repo.
`jj fix --include-unchanged-files <file...>` fixes all of the `<files>` even if they are
unchanged.
This is mostly orthogonal to other features, so not many tests are added.
This is a significant and simple enough improvement that I think it's
appropriate to make it here instead of waiting for a `jj run`-based solution.
It seems everyone agrees that `obslog` is not an intuitive name. There
was some discussion about alternatives in #3592 and on #4146. The
alternatives included `evolution`, `evolutionlog`, `evolog`,
`rewritelog`, `revlog`, and `changelog`. It seemed like
`evolution-log`/`evolog` was the most popular option. That also
matches the command's current help text ("Show how a change has
evolved over time").
As reported in #4394, at least `test_show_command::test_show_basic`
can fail when run with a narrow terminal. This patch sets
`COLUMNS=100` in the environment when running tests so the CLI uses
that value instead of using the width of the user's terminal.
This doesn't provide any benefit yet bit I think we've known for a
while that we want to make the backend write methods async. It's just
not been important to Google because we have the local daemon process
that makes our writes pretty fast. Regardless, this first commit just
changes the API and all callers immediately block for now, so it won't
help even on slow backends.
When building this project with [Nix/Crane](https://github.com/ipetkov/crane/discussions/693), if the `jj-cli` dependency is specified in `Cargo.toml` as a git-based crate, `cargo vendor` splits this workspace up into sub-crate directories, which causes `cargo metadata` to fail when searching for relative deps in the workspace root.
This commit simply changes how the crate version is determined, using Cargo's built-in environment variable [`CARGO_PKG_VERSION`](https://doc.rust-lang.org/cargo/reference/environment-variables.html)
Right now, renamed and copied files don't have any color in the output
of `jj status`, and it makes them stand out. I think it's reasonable to
color renamed files the same as modified files, since renaming is like
modifying the path, and to color copied files the same as added files,
since they're basically just added files that happen to have similar
contents to an existing file.
This avoids cloning `UserSettings` and some other data. I haven't
attempted to measure the performance impact (I expect it's tiny); this
is more about clarifying that there are not multiple different
versions of these fields.
This wraps all the fields in `CommandHelper` in an `Rc` so
`CommandHelper` itself becomes cheap to clone (thanks to @yuja for the
idea). I'll use that next to avoid some cloning in
`WorkspaceCommandHelper`.
"Concurrent" operations are not necessarily actually concurrent, so
"divergent" seems like a better name. And "reconcile" seems like a
better term for merging them, though we also sometimes use "merge".
Like https://github.com/martinvonz/jj/pull/4189, this allows extensions the ability to load the repo in an environment where the local filesystem is not accessible. This change allows such extensions to exist at the CLI layer where jj is invoked as a subprocess, rather than a library (common in testing).
I played with max-inline-alternation = 3 for a couple of weeks, and it's pretty
good. I think somewhere between 2 and 4 is good default because one or two
remove + add sequences are easy to parse.
FileConflict will be changed to not materialize Merge<BString>. I also updated
the revset engine to ignore non-file conflict. It doesn't make sense to grep
conflict description.
If movement commands don't find a target commit, they fail. However,
it's usually not intuitive why they fail because in non-edit mode the
start commit is the parent of the working commit.
Adding the start commit change hash to the error message makes it easier
for the user to figure out what is going on.
Also, specifying 'No **other** descendant...' helps make it clear what
`jj` is really looking for.
Part of #3947
Not all callers need this information, but I assumed it's relatively cheap to
look up the source path in the target tree compared to diffing.
This could be represented as Regular(_)|Copied(_, _)|Renamed(_, _), but it's
a bit weird if Copied and Renamed were separate variants. Instead, I decided
to wrap copy metadata in Option.
This patch adds accessor methods as I'm going to change the underlying data
types. Since entry values are consumed separately, these methods are implemented
on CopiesTreeDiffEntryPath, not on *TreeDiffEntry.
