Commit graph

62 commits

Author SHA1 Message Date
Yuya Nishihara
552c71ed36 tests: move commit_transactions() helper to testutils 2023-08-10 06:27:16 +09:00
Martin von Zweigbergk
56109bda38 tests: another attempt to fix remaining flaky tests in test_view.rs
This is another commit like 0f3bd7fb03 and 8e7e32710d. I don't
know how I didn't catch all remaining instances last time :(
2023-08-04 23:36:15 +00:00
Martin von Zweigbergk
4a10ea4e3e tests: attempt to fix more flaky tests in test_view.rs
This is the same kind of fix as in 8e7e3271. I should have just fixed
all instances then.
2023-08-04 21:13:30 +00:00
Yuya Nishihara
4834d12c37 simple_op_store: serialize RefTarget in new format (breaks downgrades)
This is breaking change. Old jj binary will panic if it sees a view saved by
new jj. Alternatively, we can store both new and legacy data for backward
compatibility.
2023-07-27 15:32:48 +09:00
Yuya Nishihara
443391bf8f view: store Option<RefTarget> in maps, add extension trait to flatten Option
Alternatively, we can wrap BTreeMap<String, Option<RefTarget>> to flatten
Option<&Option<..>> internally, but doing that would be tedious. It would
also be unclear if map.remove(name) should construct an absent RefTarget if
the ref doesn't exist.
2023-07-18 18:12:09 +09:00
Yuya Nishihara
7461370f6e view: add wrapper that will exclude absent RefTarget entries from ContentHash
The next commit will change these maps to store Option<RefTarget> entries, but
None entries will still be omitted from the serialized data. Since ContentHash
should describe the serialized data, relying on the generic ContentHash would
cause future hash conflict where absent RefTarget entries will be preserved.

For example, ([remove], [None, add]) will be serialized as ([remove], [add]),
and deserialized to ([remove], [add, None]). If we add support for lossless
serialization, hash(([remove], [None, add])) should differ from the lossy one.
2023-07-18 18:12:09 +09:00
Martin von Zweigbergk
8e7e32710d tests: attempt to fix a flaky test
We saw a failure in `test_merge_views_git_heads()` in the GitHub CI,
but I wasn't able to reproduce it locally. Using the
`commit_transactions()` helper in the test should fix it.
2023-07-16 23:06:13 +01:00
Yuya Nishihara
a1e92563ae refs: add constructor of Some(RefTarget::Conflict { .. })
It's named after Conflict::from_legacy_form(). If RefTarget is migrated to
new Conflict type, from_legacy_form([], [add]) will create a normal target,
and from_legacy_form([], []) will be equivalent to the current None target.
That's why this function isn't named as RefTarget::conflict().
2023-07-17 01:13:21 +09:00
Yuya Nishihara
e55c533add refs: add constructor of Some(RefTarget::Normal(id))
If RefTarget is migrated to new Conflict type, this function will create
RefTarget(Conflict::resolved(Some(id))).

We still need some .unwrap() to insert Option<RefTarget> into map, but maps
will be changed to store new RefTarget type, and their mutation API will
guarantee that Conflict::resolved(None) is eliminated.
2023-07-17 01:13:21 +09:00
Yuya Nishihara
d80a719042 view: unify set/remove_local_branch() functions to take Option<RefTarget> 2023-07-15 05:57:49 +09:00
Yuya Nishihara
78eea06c36 view: unify set/remove_remote_branch() functions to take Option<RefTarget> 2023-07-15 05:57:49 +09:00
Yuya Nishihara
fc609a6d8d view: unify set/remove_tag() functions to take Option<RefTarget> 2023-07-15 05:57:49 +09:00
Yuya Nishihara
3be462266c view: unify set/remove_git_ref() functions to take Option<RefTarget>
New function takes name by reference since it doesn't always need an owned
String.
2023-07-15 05:57:49 +09:00
Yuya Nishihara
5218591a82 view: unify set/clear_git_head() functions to take Option<RefTarget>
If we migrate RefTarget to new Conflict-based type, it won't store
Conflict<CommitId>, but Conflict<Option<CommitId>>. As the Option will
be internalized, new RefTarget type will also represent an absent target.
The 'target: Option<RefTarget>' argument will be replaced with new RefTarget
type.

I've also renamed the function for consistency with the following changes.
It would be surprising if set_local_branch(name, target) could remove the
branch. I feel the name set_local_branch_target() is less confusing.
2023-07-15 05:57:49 +09:00
Martin von Zweigbergk
aac5b7aa25 cargo: rename crates from jujutsu/jujutsu-lib to jj-cli/jj-lib
Almost everyone calls the project "jj", and there seeems to be
consensus that we should rename the crates. I originally wanted the
crates to be called `jj` and `jj-lib`, but `jj` was already
taken. `jj-cli` is probably at least as good for it anyway.

Once we've published a 0.8.0 under the new names, we'll release 0.7.1
versions under the old names with pointers to the new crates names.
2023-07-09 06:40:43 +02:00
Martin von Zweigbergk
f6a4cb57da repo: extract a Repo trait for Arc<ReadonlyRepo> and MutableRepo
This will soon replace the `RepoRef` enum, just like how the `Index`
trait replaced the `IndexRef` enum.
2023-02-15 19:15:17 -08:00
Martin von Zweigbergk
fafa9b70fc view: also merge git_heads when merging views
I don't know if I had just forgotten to merge `git_heads` when I added
it to the view object, but it seems like it should be merged just like
refs.
2023-01-30 09:05:03 -08:00
Martin von Zweigbergk
4e8fbaa210 git: allow conflicts in "HEAD@git"
Git's HEAD ref is similar to other refs and can logically have
conflicts just like the other refs in `git_refs`. As with the other
refs, it can happen if you run concurrent commands importing two
different updates from Git. So let's treat `git_head` the same as
`git_refs` by making it an `Option<RefTarget>`.
2023-01-30 09:05:03 -08:00
Martin von Zweigbergk
10725c095f cleanup: update more "checkout" to "working-copy commit" and similar
I've preferred "working-copy commit" over "checkout" for a while
because I think it's clearer, but there were lots of places still
using "checkout". I've left "checkout" in places where it refers to
the action of updating the working copy or the working-copy commit.
2023-01-25 11:02:59 -08:00
Daniel Ploch
bd43580437 op_heads_store: remove LockedOpHeads
Make op resolution a closed operation, powered by a callback provided by the
caller which runs under an internal lock scope. This allows for greatly
simplifying the internal lifetime structuring.
2023-01-20 15:18:08 -08:00
Martin von Zweigbergk
d86ba708a3 repo: add MutableRepo::rewrite_commit() returning CommitBuilder
Same reasoning as the previous commit.
2022-12-26 23:30:52 -08:00
Martin von Zweigbergk
f3208f59c4 store: propagate error from Backend::write_commit() 2022-12-26 23:30:52 -08:00
Martin von Zweigbergk
f1d7bbe508 testutils: create a function for writing a random commit to MutableRepo
We already have `create_random_commit()`, which returns a
`CommitBuilder`. Most callers directly write that to a
`MutableRepo`. That currently returns a `Commit`, but I'm about to
make it propagate errors from the backend. That would add an
`unwrap()` to this sequence, making it longer. Let's create a simple
helper for these callers to simplify this common pattern.
2022-12-26 23:30:52 -08:00
Martin von Zweigbergk
49b2f3b6ca commit_builder: keep MutableRepo reference
When you're done with the `CommitBuilder`, you're going to have to
call `write_to_repo()`, passing it a mutable `MutableRepo`
reference. It's a bit simpler to pass that reference when we create
the `CommitBuilder` instead, so that's what this patch does.

A drawback of passing in the mutable reference when we create the
builder is that we can't have multiple unfinished `CommitBuilder`
instance live at the same time. We don't have any such use cases yet,
and it's not hard to work around them, so I think this change is worth
it.
2022-12-26 23:30:52 -08:00
Yuya Nishihara
986649623d commit_builder: relax type of description parameter
The next commit will introduce a newtype for -m/--message argument which
can be converted Into<String>.

Since CommitBuilder is a thin wrapper, code bloat caused by generic parameters
wouldn't matter. I have another set of commits that makes all builder methods
accept Into/IntoIterator, which will remove some of .clone() calls from tests.
2022-12-22 14:59:03 +09:00
Martin von Zweigbergk
b80c39d77c view: test that merging divergent rewrites results in both commits visible
It seems that we didn't have a test for this simple case. I wrote this
test case while working on #111 but I don't know why I didn't push it
back then.
2022-12-01 19:20:38 -08:00
Martin von Zweigbergk
d8feed9be4 copyright: change from "Google LLC" to "The Jujutsu Authors"
Let's acknowledge everyone's contributions by replacing "Google LLC"
in the copyright header by "The Jujutsu Authors". If I understand
correctly, it won't have any legal effect, but maybe it still helps
reduce concerns from contributors (though I haven't heard any
concerns).

Google employees can read about Google's policy at
go/releasing/contributions#copyright.
2022-11-28 06:05:45 -10:00
Martin von Zweigbergk
9502d84872 operations: make hostname and username configurable
We currently get the hostname and username from the `whoami` crate. We
do that in lib crate, without giving the caller a way to override
them. That seems wrong since it might be used in a server and
performing operations on behalf of some other user. This commit makes
the hostname and username configurable, so the calling crate can pass
them in. If they have not been passed in, we still default to the
values from the `whoami` crate.
2022-11-14 10:02:04 -08:00
Martin von Zweigbergk
eb89f6b6ca tests: consistently import create_random_tree()
These calls often appear in expressions long enough that not having to
qualify it means that we can sometimes avoid wrapping a line. I
noticed because IntelliJ told me that `test_git.rs` had some
unnecessary qualificiations (the function was already imported there).
2022-11-13 15:06:10 -08:00
Martin von Zweigbergk
3c7c4e9f5c tests: move testutils module into separate crate
The `testutils` module should ideally not be part of the library
dependencies. Since they're used by the integration tests (and the CLI
tests), we need to move them to a separate crate to achieve that.
2022-11-08 07:29:35 -08:00
Benjamin Saunders
037eaaf36c repo: forbid checking out the root commit
Prevents `jj edit root` from succeeding, which would otherwise place
the repo in a state where every operation panics.
2022-10-21 10:10:07 -07:00
Martin von Zweigbergk
6812bd9584 cleanup: rename checkout to wc_commit
`wc_commit` seems clearer than `checkout` and not too much longer. I
considered `working_copy` but it was less clear (could be the path to
the working copy, or an instance of `WorkingCopy`). I also considered
`working_copy_commit`, but that seems a bit too long.
2022-09-18 16:19:58 -07:00
Martin von Zweigbergk
1b5cd140d5 CommitBuilder: remove unneeded store arguments
The `CommitBuilder::store` field is used only in
`CommitBuilder::write_to_repo()`, but we can easily get access to the
`Store` from the `repo` argument there, so let's remove the field.
2022-07-06 07:21:57 -07:00
Martin von Zweigbergk
5c6f82ec7b tests: remove &UserSettings argument from TestRepo::init()
We don't even have any settings that affect the repo, so there's no
point in passing the settings. I think this was a leftover from before
we separated out the "workspace" concept; now we no longer create a
working-copy commit when we initialize a repo (we do that when we
attach the workspace).
2022-05-21 22:33:16 -07:00
Martin von Zweigbergk
4cf04f373e tests: move init_{repo,workspace} functions onto types
I tried to create a `TestRepo` and was surprised that I couldn't do
that by calling a function on it.
2022-05-21 22:33:16 -07:00
Martin von Zweigbergk
543a95c653 rewrite: propagate backend errors in DescendantRebase::rebase_next() 2022-05-02 08:05:24 -07:00
Martin von Zweigbergk
04ad9a3628 repo: when merging in removed head, rebase descendants (#111) 2022-03-26 22:31:49 -07:00
Martin von Zweigbergk
ec84de7779 repo: clarify that some repo functions load the repo at head (#111) 2022-03-26 22:31:49 -07:00
Martin von Zweigbergk
dabfd04da6 tests: attempt to de-flake operation-merging test
We resolve checkouts in favor of the first-committed operation (which
is more likely to have managed to update the working copy). The test
case has been flaky on GitHub lately. I've run it 1000 times on my
machine without failure. I don't know if GitHub's machines are just
faster in some way (SSD, maybe) that makes them finish the two
operations in the test in the same millisecond. Let's add a
1-millisecond sleep to see if that helps. If it doesn't, then maybe
the issue is that the clock has lower precision (or their clocks can
go backwards?).
2022-02-09 11:15:10 -08:00
Martin von Zweigbergk
0fd3b8ef1a tests: don't create workspaces in view tests
Even the checkout tests need only a repo!
2022-02-05 13:47:48 -08:00
Martin von Zweigbergk
abedeeaacf tests: rename init_repo() to init_workspace()
Most tests need a repo but don't need a working copy. Let's have a
function for setting up a test repo. But first, let's free up the name
`init_repo()` by renaming it to `init_workspace()` (which is also more
accurate).
2022-02-05 13:02:19 -08:00
Martin von Zweigbergk
6d3e2017f8 view: merge checkouts for all workspaces, not just the default one (#13) 2022-02-02 08:15:22 -08:00
Martin von Zweigbergk
766c01a6d9 view: add workspace_id argument to set_checkout() (#13) 2022-02-02 08:15:22 -08:00
Martin von Zweigbergk
ce094f64d5 testutils: make init_repo return a struct, including a Workspace
This is a fairly mechanical change; I'll do some minor cleanups in
later commits.
2021-11-25 21:04:56 -08:00
Martin von Zweigbergk
6c0f3625ff tests: avoid accessing working copy just to get its commit ID
The view has been the source of truth for the currently checked-out
commit for a long time now.
2021-11-17 12:45:18 -08:00
Martin von Zweigbergk
41ebdea415 tests: update a test to not point a branch to an unreachable commit
The next patch would otherwise make this test fail because
"transaction 2" tries to point a branch to a commit that's not visible
(because it's created by the concurrent "transaction 1").
2021-10-02 23:08:45 -07:00
Martin von Zweigbergk
ff71af1e11 MutableRepo: accept just CommitId instead of whole Commit where possible 2021-09-29 10:13:32 -07:00
Martin von Zweigbergk
ce5e95fa80 store: rename Store to Backend and StoreWrapper to Store
For what's currently called `Store` in the code, I have been using
"backend" in plain text. That probably means that `Backend` is a good
name for it.
2021-09-12 12:02:10 -07:00
Martin von Zweigbergk
044f23bc33 view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.

For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).

This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.

I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-08-04 11:33:57 -07:00
Martin von Zweigbergk
b1e60b37ea view: add tests of merging views
I'm about to add some support for branches and tags (for issue #21)
and it seems that we didn't have explicit testing of merging of
views. There was `test_import_refs_merge()` in `test_git.rs` but
that's specifically for git refs. It seems that it's made obsolete by
the tests added by this commit, so I'm removing it.
2021-08-04 11:33:57 -07:00