We want these to be `Send` and `Sync` so we can send them between
threads in our multi-threaded backend. This requires a bunch of subsequent
(but obvious) changes throughout cli and the tests.
Co-authored-by: Benjamin Brittain <ben@ersc.io>
Signed-off-by: Austin Seipp <austin@ersc.io>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
formatter.with_label(..) API is getting complicated, and I'm thinking of
replacing .with_label*() functions with .labeled() that will do .pop_label() on
Drop.
This patch means that the last escape sequence is more likely emitted by Drop,
which is less reliable. However, in practice, output payload is terminated by
newline, and therefore, reset sequence would have been emitted by write().
Ignoring io::Error in Drop wouldn't be horrible either since subsequent write()
on the same stream would likely fail.
It seemed odd that we had to pass ConflictMarkerStyle to snapshot functions.
Suppose materialize/parse functions aren't lossy, we can compare hunks in
Vec<Merge<BString>> form. This should also be robust for configuration changes.
test_materialize_parse_roundtrip_different_markers() is simplified as there
should no longer be "pair" of marker styles.
It's odd that cmd_help() returns an error for valid arguments. Let's look up the
target command explicitly. We still need to do app.try_get_matches_from_mut() to
initialize clap::Command internals, though.
We haven't written legacy/path-level conflicts since jj 0.11 (Nov
2023). This patch makes the Git backend return legacy conflicts as the
regular JSON-containing files they are represented by.
Legacy trees (those with conflicts recorded at the path level) have
not been created since 0.11 (Nov 2023). We're about to deprecate them
now. This patch removes support for them in the working copy. If
anyone still has a commit checked out at a legacy tree, we will now
interpret that as a modern tree, meaning that any conflicts will
appear as regular files with JSON contents in the previous snapshot,
so if we re-snapshot the working copy (and e.g. the mtime has
changed), these files will become resolved with the conflicts markers
still in them.
I think it's quite unlikely that anyone has working copies this old so
I didn't mention it in the changelog.
The pico text editor is effectively absent from the majority of Linux
distributions, having been replaced with nano by virtually all of them.
Some distros have symlinks for `pico` that point to `nano`, but not all
of them. Using nano as the fallback option has a much lower chance of
failure than pico.
Co-authored-by: Remo Senekowitsch <remo@buenzli.dev>
This adds a command that automatically bisects a range of commits
using a specified command. By not having the interactive kind
(e.g. `jj bisect good/bad/skip/reset`), we avoid - for now at least -
having to decide where to store the state. The user can still achieve
interactive bisection by passing their shell as the bisection command.
Closes#2987.
Closes https://github.com/jj-vcs/jj/issues/7189
Colocated repos have some advantages and some disadvantages. On the
whole, I think making Git repos colocated by default is a better
trade-off, especially for new users. With the `git.colocate` setting,
(experienced) users can easily change this according to preference.
A non-exhaustive list of pros and cons of colocated repos:
pros:
* Many code editors show the changes one is currently working on based
on Git's "dirty worktree".
* There are a lot of tools that integrate with Git which don't work at
all in non-colocated repositories.
* There are a lot of Git features that Jujutsu doesn't have yet. When
users ask for them, the answer is usually: "Just colocate your repo
and run git directly for now." It's a strength that Jujutsu can focus
on what makes it special and not have to rush the reimplementation of
every niche feature of Git. Examples: `git rebase` tracking file
renames, `git bisect`, `git tag`, `git range-diff`, submodules.
cons:
* Jujutsu performs worse in colocated repositories with lots of refs,
because of the automatic `jj git import`.
* Colocated repos make branch@git references show up in Jujutsu output,
which is usually just aesthetically displeasing or possibly even
confusing to inexperienced users.
* Interleaving jj and (mutating) git commands can lead to confusing
situations. Examples:
* Creating a commit with git instead of jj will often leave a
duplicate "work in progress" commit in Jujutsu's log.
* Some IDEs periodically run `git fetch` in the background. This can
lead to conflicted branches and divergent change IDs, something many
people struggle with.
The [vars] section is used to define the tool versions, and the tools
are only declared in each task in order to be able to run a task and
install only the required dependencies. This way
mise build:docs
only install the docs dependencies, but not the rust toolchain.
The task are organized hierarchically, allowing to run all of the tasks
in a category, for example with
mise run "check:*"
Some aliases for the most common tasks are defined in order to keep the
command line short and easy to type. For example use
mise test squash
to run all the squash tests.
Co-authored-by: Emily <artyom@artyom.me>
There were some concerns that `touch` only makes sense if you're
familiar with the Unix `touch` command. I think that's a fair
concern. I did not hear any objections to renaming the command. If
we're going to do it, we should do it now, so it doesn't ever get
released under the old name.
Note that the actual error message is almost always the same. They all end up
with the message "Failed to read working copy state" in `tree_state`. So the
original code adding another equivalent message is unnecessary.
I'm thinking of adding an option to do word-by-word merging, which will be pass
down to files::merge_hunks() through materialize_merge_result*(). Since tree
merging should also respect this option, it will be carried by the Store, and
copied to ConflictMaterializeOptions.
Copying from Discord:
@ilyagr recently accepted a job offer from East River Source Control
(ersc.io). That means we will have two of the five maintainers from
that company (@thoughtpolice is the other one), which is more than the
1/3 that our policy allows
(https://github.com/jj-vcs/jj/blob/main/GOVERNANCE.md#single-company-influence). To
resolve it, we decided to add more maintainers. We're happy to
announce that both @bnjmnt4n and @scott2000 have agreed to join. Thank
you!
This is a basic implementation of the same string pattern system as in
the revset language. It's currently only used for `string.matches`, so
you can now do:
```
"foo".matches(regex:'[a-f]o+')
```
In the future this could be added to more string functions (and e.g.
the ability to parse things out of strings could be added).
CC: https://github.com/jj-vcs/jj/issues/6893
When I run the same command as CI, `cargo +stable clippy --all-features --workspace --all-targets -- -D warnings` I previously got errors such as:
```
error: the following explicit lifetimes could be elided: 'a
--> cli/src/operation_templater.rs:365:6
|
365 | impl<'a, L: ?Sized, P> OperationTemplateBuildFnTable<'a, L, P> {
| ^^ ^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
= note: `-D clippy::needless-lifetimes` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::needless_lifetimes)]`
help: elide the lifetimes
|
365 - impl<'a, L: ?Sized, P> OperationTemplateBuildFnTable<'a, L, P> {
365 + impl<L: ?Sized, P> OperationTemplateBuildFnTable<'_, L, P> {
|
```
This fixes the errors that I'm getting locally, and also enables the
same lints on CI.
Now that https://github.com/jj-vcs/jj/pull/7275 has merged it's worth
mentioning that simple fetch refspecs will (now) be respected when other
branches are otherwise not specified on the CLI
Rustdoc was losing the formatting of the merge diagrams in
`Merge::flatten()`'s doc comment; preserve it with an HTML `<pre>`
block.
Also remove a stray backtick that broke formatting in
`Merge::to_file_merge()`'s doc comment.
Tombi is an LSP that complains about the "$schema" key, because it
itself is not actually part of our schema. Taplo is another LSP that
can read this comment directive. Using a comment seems generally more
appropriate. Syntax highlighting makes comments usually less visible,
indicating that the directive is not actually part of the configuration
data.
This means `f ()`, `x . f()`, etc. are now allowed. Before, `x\n.f()` was syntax
error, which seemed unintuitive in multi-line expression.
This also means that whitespace around alias declaration is ignored.
tempalte-aliases.' foo ' is identical to tempalte-aliases.foo.
https://pest.rs/book/grammars/syntax.html#implicit-whitespaceCloses#7378
I considered adding more details, but ultimately decided to err on the
side of brevity. We could later write a short doc detailing the behavior
(see the comments in the source) and point the CLI docs to it.
For now, I tried to explain the smallest mental model the users should
have in mind to feel comfortable with these commands.
Since `jj redo` is the command that really makes the notion of an "undo
stack" tick, I only mentioned that notion in there.
Follows up on #7293 and #7277
A lot of breaking changes and deprecations are about `undo`, so it feels right
to mention `redo` soon after. We often rearrange the changelog during a release,
but this stood out to me, so why not do it now.
After a change has been accidentally modified, the user may want to
recover the original revision with the same commit ID if it was pushed
to a remote, not just restore the original contents.
Instead of using `jj restore` to restore contents, recommend using `jj
new <PREVIOUS_ID>` to unhide the original commit. This strategy works
whether or not the user cares about the original commit ID.
This implements the steps 3-4 described in "When Should You Fsync?"
https://lwn.net/Articles/457667/
With my testing on Linux VM, persisted op_store file names (or directory entry)
can occasionally lost as well as op_heads entries. We can insert fsync(dir_fd)
to fix these, but then we'll get data corruption somewhere in Git object store.
Since Git/gix writes small files more frequently, I don't think we can easily
address the problem at gix side. I think the current state is not that bad as we
can recover from corruption relatively easily if the op_store contents are
valid.
I had this patch for months, and I didn't find any significant performance
degradation.
#4423
