With `all:` having gone away, some users (including me) had been using it
to enforce an invariant: by omitting it, an expression was guaranteed to
yield exactly one result. For example, this is important when using tools
like `jj rebase -B/-A`
Instead, let's fix that case by building that functionality into the
revset language itself. The previous behavior can now be enforced via
the term `exactly(x, 1)`
In the future, `n` could also be a range.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This code was added by 4af678848d "op_store: minimal change to load/store
tracking state of remote branches" (2023-10-16). It's unlikely that the head
operation was written by jj older than that. Remote refs in old views are now
mapped to State::New unconditionally, which should be okay for read-only
operations.
`MergeOptions` isn't currently used directly in either module but it's
more closely related to `tree_merge`. It's possible we will want to
pass it into `ConflictIterator`, however.
`merged_tree.rs` is getting too big. The code for merging/resolving
trees is quite well separated from `MergedTree`'s core logic of
creating a view of the merged input trees on the fly.
I have no idea if we can change the default, but maybe we can conditionally
disable the same-change rule to get rid of hacks in squash_commits(), etc.?
resolve_file_executable() doesn't respect the Store configuration. I'm not sure
if that's the right choice, but it seemed better to accept duplicated change
than falling back to executable=false.
#6369
I'll add same-change rule parameter to disable A+(A-B)=A resolution. Since tree
merging involves content merging, file-level parameters should also be included
in the "tree" merge options. We could add a nested options type, but I don't
think we'll add an option that applies only to tree-level merging. So this patch
unifies these options types as MergeOptions.
merge_ref_targets() uses SameChange::Accept rule explicitly. Since ref changes
are resolved based on ancestry, it seems good to resolve same-change conflicts
as well.
Adds a new `--when.platforms` condition for including configuration.
This is useful when someone syncs their dotfiles across machines.
The values for `platforms` are defined by `std::env::consts::FAMILY` and
``std::env::consts::OS. Any Unix-family platform can be specified using
the value `"unix"`, or individual operation systems can be chosen with
`"linux"`, `"macos"`, or `"windows"`.
Example:
```toml
ui.pager = ["less", "-FRX"]
[[--scope]]
--when.platforms = ["windows"]
ui.pager = ["C:/Program Files/Git/usr/bin/less.exe", "-FRX"]
```
This option affects emptiness of commits, which means indexed changed files can
become stale on configuration change. This problem can also be said for changes
in the diff algorithms, so I don't think we need a logic to invalidate index on
config change.
I have this patch for months, and it seems working good at least for Rust
sources.
Closes#17
I'll add word-by-word merging flag. Since we need to run auto-merge with the
configured options, these options are carried by the Store for now. When we add
a "jj resolve" flag to run auto-merge with different configuration, we might
have to parameterize the options passed in to MergedTree::resolve().
As suggested by @PhilipMetzger
The word "grey" is whitelisted because
- we have a contributor of that name
- we use a library that uses "Grey" as a member of an enum
- I refuse to believe "grey" is not US English
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>
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.
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.
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.
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.
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 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
