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
With this patch, init() would no longer panic when the checkout state already
existed. This should be okay because the caller always create new workspace
directory.
Since Index is now implemented for CompositeIndex instead of &CompositeIndex,
these two functions have exactly the same signature. We no longer need a
specialized implementation to correct lifetime of the return value.
I don't have a strong feeling whether we should add "entry.commit() -> Commit"
method or forward method calls to the Commit object, but this patch implements
the former because:
a. evolution_entry.diff() should return inter diff, whereas commit.diff()
doesn't.
b. auto-labeling works if self.commit() is an explicit method call.
c. the implementation and documentation can be simple.
Tests will be added by the next patch.
Commit::is_empty() and ::parent_tree() will query index first to avoid merging
parent trees.
iirc, the Google backend has an index of changed paths, so I made the added
function return Result although the default index will never fail. I also
considered adding matcher argument, but I don't have any use case right now. I
think the Matcher API would be too abstract to construct a database query. Maybe
we should use Revset/FilesetExpression types for that purpose.
We ran into the following error when upgrading to the latest unstable
rustc at Google when compiling our internal commit backend:
```
overflow evaluating the requirement `impl futures::Future<Output = Result<jj_lib::tree::Tree, jj_lib::backend::BackendError>>: Sized`
```
It seems to be some limitation of rustc related to recursion and async
functions but we don't know what exactly it means.
This patch works around that by making the async part of
`merge_commit_trees_no_resolve_without_repo()` non-recursive. There is
still a recursive part, but it's no longer async. The recursive part
now finds all the commit IDs involved. Then we do the lookup of them
afterwards.
We may want to make the remaining recursive part non-recursive as well
so don't run out of stack on a long braid of criss-cross merges, but
that can come later.
We didn't seem to have a test case of the recursive merge
implementation (no tests failed when I changed it to always use the
first ancestor instead of being recursive).
By default `git clone` will fetch all tags on a remote (unless
`--no-tags` is specified). Eventually we'll want to support the same
behavior, though since we first configure a remote and then fetch, we'll
need to configure the remote with the correct *general* tag fetching
behavior, but still perform the first fetch with all tags included.
This paves the way for the semantics of `jj undo` and `jj op revert` to
evolve independently. `jj op revert` is going to stay the low-level
command to apply the inverse of any operation. The new name is
consistent with `jj revert`, which applies the inverse of a commit.
`jj undo` on the other hand is planned to become a higher-level command,
which is more similar to, say, Ctrl+Z in typical GUI applications.
Running `jj undo` repeatedly will revert progressively older operations,
allowing the user to walk backwards in time. At the same time, `jj undo`
will lose the abilitly to revert arbitrary operations, to keep its
semantics simple and intuitive.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
The current implementation does linear search, which I think is good assuming
the size of the changed paths set is usually small. The next costly part of "jj
log PATH" is commit.empty() template on merge commits (#5411). We'll need a
public API to query changed-path index to optimize it.
