Commit graph

577 commits

Author SHA1 Message Date
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
a382e96168 revset_graph: place new heads as close to fork point as possible
The idea is simple. New heads are ignored until the node dependency resolution
stuck. Then, only the first head that will unblock the visit will be queued.

Closes #242
2023-07-25 01:45:37 +09:00
Yuya Nishihara
fb33620f9e revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.

I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.

https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting

Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.

#242
2023-07-25 01:45:37 +09:00
Ilya Grigoriev
df6d953116 cli: render HEAD@git in green instead of bright green
To me, green looks less distracting. Also, we mostly use bright colors for
the working copy commit.

This follows up on #1844.
2023-07-11 08:04:46 -05:00
Austin Seipp
5c82100ef0 fix(config): by default, render git refs as green instead of magenta
Summary: Someone on Discord mentioned that while using branches, they could
switch between branches like `m1` and `main`, but not `HEAD@git`, even though it
was color coded the same and located right next to the other branch names in the
default `jj log` output.

This confused me too at first, until I realized `jj` was telling me that the
given commit was the `HEAD` reference in the colocated git repo. Let's just
color these references differently in the default schema, to try and hint that
these aren't the same. `bright green` is arbitrary, but helps stand out; and
`green` was only picked because both it and `git` start with "g".

GitHub Issue: #1843

Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I66d53ea2b9155db1fec6cae8ba8cbd0f
2023-07-10 22:33:02 -05:00
Yuya Nishihara
9aa308fb4a revset: include pseudo @git remote in suggestion
Since collect_branch_symbols() doesn't have to be fast, I made it simply
build a new branches map.
2023-07-10 06:17:44 +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
Yuya Nishihara
3e294ca2d6 revset: do not suggest deleted local branches, suggest @remote branches
It seemed too verbose to always include @remote branches, so synced remotes
are omitted by default. If the given symbol contained '@', all remote symbols
are populated so that the distance of remote fragment is taken into account.
2023-07-09 10:42:14 +09:00
Yuya Nishihara
4a5060a618 revset: don't resolve deleted branch symbol to empty set
A deleted branch disappears immediately if there's no remote counterpart,
so I don't think a local name should be resolvable like zombie.
2023-07-09 10:42:14 +09:00
Yuya Nishihara
d58702cd63 templater: include pseudo @git targets in branches keyword
#1666
2023-07-09 10:39:43 +09:00
Yuya Nishihara
85d87e2658 cli: warn if loosely selected push targets include conflicted branches 2023-07-08 10:23:21 +09:00
Yuya Nishihara
a3d080580e cli: on git push, do not ignore conflicting branch at @
If @ is pointed by any branch, we shouldn't fall back to @-.
2023-07-08 10:23:21 +09:00
Yuya Nishihara
16bf861e3b tests: add "git push" tests involving conflicting branches 2023-07-08 10:23:21 +09:00
Yuya Nishihara
868188c84e repo: handle empty .jj repo gracefully, include file path in error message 2023-07-06 20:48:46 +09:00
Yuya Nishihara
cf8a0466c4 backend: introduce error types specific to init/load phases
Errors that may occur while loading backend would vary per backends, and
it's unlikely that these errors could be mapped to BackendError variants
other than BackendError::Other. So let's extract Other(_) of that kind as
a separate type to clarify there would be no other error variants.

Perhaps, Backend/Error will be renamed to CommitBackend/Error or
CommitStore/Error?, whereas I think BackendInit/LoadError can be shared
among store factories.
2023-07-06 20:48:46 +09:00
Yuya Nishihara
5b78fe75b1 git_backend: propagate load() error to caller
#1794
2023-07-06 12:43:49 +09:00
Ilya Grigoriev
8645153946 undo: preserve git-tracking refs in colocated repos by default 2023-07-03 12:28:06 -07:00
Ilya Grigoriev
63fe67bf74 undo: options to preserve git refs and/or remote-tracking branches on undo or restore 2023-07-03 12:28:06 -07:00
Ilya Grigoriev
e684010a68 test_git_import_export: no-op change to a test 2023-07-03 12:28:06 -07:00
Ilya Grigoriev
89651465d3 test_undo: three versions of the git_push_undo test
The original test is copied from @martinvonz 's [PR draft] (thanks!).

The three versions show differences in behavior due to import/export
of remote-tracking branches, and due to repo being colocated.

The former is relevant for [the discussion] of whether `jj git export` should
export remote-tracking branches. The latter will change in a follow-up commit.

Outstanding TODO: check if we have similar tests for undoing `fetch`

[PR draft]: https://github.com/martinvonz/jj/pull/1541
[the discussion]: https://github.com/martinvonz/jj/pull/1739
2023-07-03 12:28:06 -07:00
Ilya Grigoriev
51d61b6a20 test utilities: advance_test_rng_seed_to_multiple_of function 2023-07-03 12:28:06 -07:00
Ilya Grigoriev
371e7f46e2 git fetch: do a git export of deleted branches before fetch 2023-07-03 11:01:22 -07:00
Ilya Grigoriev
59b354992a git export: export deletion of forgotten remote-tracking branches 2023-07-03 11:01:22 -07:00
Yuya Nishihara
d3c031b277 tests: add helper method to capture both stdout/stderr outputs
This pattern is common, and should have a shorthand so that we can easily
add warning messages.
2023-07-03 22:03:05 +09:00
Yuya Nishihara
cefbeba776 cli: add revset filter to "branch list"
Typical query would be something like -r 'mine()' or -r 'branches()' to
exclude remote-only branches #1136.

The query matches against local targets only. This means there's no way to
select deleted/forgotten branches by -r option. If we add a default revset
configuration, we'll need some way to turn the default off.
2023-07-02 14:39:45 +09:00
Ilya Grigoriev
335e86d8e7 test_branch_command: use bare repositories
Otherwise, those tests cannot use `jj git push`. This is an issue with a test
in the next commit, and I don't want people to copy these tests and be surprised.
2023-06-30 21:29:24 -07:00
Ilya Grigoriev
333c348fb9 branch forget & delete: report if forgot/deleted multiple branches 2023-06-30 21:29:24 -07:00
Ilya Grigoriev
f6ddd775b9 branch delete: allow deleting globs of branches 2023-06-30 21:29:24 -07:00
Ilya Grigoriev
144a44914a branch forget: error message if no globs match 2023-06-30 21:29:24 -07:00
Yuya Nishihara
e601a30b15 cli: make log accept multiple -rREVISION expressions
For scripting scenario, multiple -r options are easier to construct than
concatenating expressions with ")|(".
2023-06-29 19:33:32 +09:00
Glen Choo
777b786c53 git: add a hidden submodule subcommand
Add the `submodule` subcommand, which will remain hidden while we are
polishing up the submodules feature. Also, add a debugging-only
sub-subcommand `print-gitmodules` that tests our .gitmodules parser with
the .gitmodules in the working copy.
2023-06-27 10:07:00 -07:00
Grégoire Geis
fee7eb5813 add --edit option to jj sparse set 2023-06-27 22:56:46 +09:00
Yuya Nishihara
3c2657c393 cli: add hint for git-exporting forgotten branches
Inspired by d01ecc5c46 "more detailed message describing deleted branches."

And yes, "jj git export" does propagate "jj branch forget" to the underlying
Git repository, which strengthen my feeling that git::export_refs() should
also remove "forgotten" remote tracking refs.
2023-06-26 13:56:32 +09:00
Yuya Nishihara
72792a8dbe cli: say "(forgotten)" if branch is listed just because it's in git_refs
I thought we would need additional bookkeeping to detect forgotten branches,
but I was wrong. If a branch exists only in git_refs, it is forgotten (but not
yet exported.)
2023-06-26 13:56:32 +09:00
Ilya Grigoriev
bdb6db88e1 cli: new jj chmod command to set executable bit 2023-06-24 13:28:01 -07:00
Ilya Grigoriev
d01ecc5c46 branch list: more detailed message describing deleted branches
Fixes #1537
2023-06-24 09:23:14 -07:00
Ilya Grigoriev
e41d672cc0 branch forget: allow forgetting deleted branches
Partially fixes #1537
2023-06-24 09:23:14 -07:00
Ilya Grigoriev
89a3f8db76 test_branch_command: demo inability to forget deleted branch 2023-06-24 09:23:14 -07:00
Ilya Grigoriev
d217fe069b test_branch_command: test fetching a forgotten branch 2023-06-24 09:23:14 -07:00
Ilya Grigoriev
ee4f8f2876 test_git_fetch: move a fetch test from test_git_import_export 2023-06-24 09:23:14 -07:00
Ilya Grigoriev
08d147be32 test_git_import_export.rs: rename test and modernize terminology 2023-06-24 09:23:14 -07:00
Waleed Khan
24ea8478cb feat(config): add jj config get for scripting
The motivating use-case was this `jj signoff` script: https://gist.github.com/thoughtpolice/8f2fd36ae17cd11b8e7bd93a70e31ad6

Which includes lines like this:

```sh
NAME=$(jj config list user.name | awk '{split($0, a, "="); print a[2];}' | tr -d '"')
MAIL=$(jj config list user.email | awk '{split($0, a, "="); print a[2];}' | tr -d '"')
```

There is no reason that we should have to clumsily parse out the config values. This `jj config get` command supports scripting use-cases like this.
2023-06-23 12:07:39 -07:00
Kevin Liao
86b6a11e63 Fix jj init --git-repo fails and leaves broken .jj folder
This commit fixes #1305

Before this commit, running `jj init --git-repo=./` in a folder that
does not have a .git would cause jj to panick and leave an unfinished corrupted jj repo.

This commit fixes that by changing the call chain to return an error
instead of calling .unwrap() and panicking. This commit also adds logic to delete the unfinished jj
repository when the git backend initialization failed.

Before this commit, running the above command would result in the following
```
Running `jj/target/debug/jj init --git-repo=./`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: -3, klass: 2, message: "failed to resolve path '/Users/kevincliao/github/jj/test-repo/.jj/repo/store/../../../.git': No such file or directory" }', lib/src/git_backend.rs:83:75
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

After this commit, the result is the following and the jj repo is deleted:
```
Running `jj/target/debug/jj init --git-repo=./`
Error: Failed to access the repository: Error: Failed to open git repository: failed to resolve path '/Users/kevincliao/github/jj/test-repo/.jj/repo/store/../../../.git': No such file or directory; class=Os (2); code=NotFound (-3)
```
2023-06-20 11:02:06 -07:00
Ilya Grigoriev
096538ba18 revsets: stop jj parsing br as a git_ref refs/heads/br
Use `br@git` instead.

Before, if there is not a local branch `br`, jj tried to resolve
it as a git ref `refs/heads/br`. Unchanged from before, `br` can
still be resolved as a tag `refs/tag/br`.
2023-06-12 14:31:44 -07:00
Ilya Grigoriev
a483252cf2 revset: allow checking out git-tracking (@git) branches 2023-06-12 14:31:44 -07:00
Ilya Grigoriev
d5e8896d1b tests: demo jj branch forget behavior in colocated repos 2023-06-12 14:31:44 -07:00
Ilya Grigoriev
8df945b71d cmd: have jj branch list report git-tracking (@git) branches
This doesn't change the way @git branches are stored in `git_refs` as opposed
to inside `BranchTarget` like normal remote-tracking branches. There are
subtle differences in behavior with e.g. `jj branch forget` and I'm not sure
how easy it is to rewrite `jj git import/export` to support a different
way of storage.

I've decided to call these "local-git tracking branches" since they track
branches in the local git repository. "local git-tracking" branches sounds a
bit more natural, but these could be confused with there are no remote
git-tracking branches. If one had the idea these might exist, they would be
confused with remote-tracking branches in the local git repo.

This addresses a portion of #1666
2023-06-12 14:31:44 -07:00
Martin von Zweigbergk
ddb07e639c merge_tools: simplify error message for complex conflicts
Since e48ace56d1, the number of adds in the hunk is always exactly
one more than enumber of removes, so we can simplify the condition and
the error message accordingly.
2023-06-07 13:45:16 -07:00
Ilya Grigoriev
337544cf96 No-op clarification of import_export tests 2023-06-07 13:42:48 -07:00
Ilya Grigoriev
fa1e961f53 jj debug operation --display id option to show current operation id for tests
I also considered `jj operation id`, but I'm not sure this is useful outside tests
2023-06-07 13:42:48 -07:00