It seems better to have the caller pass the transaction description
when we finish the transaction than when we start it. That way we have
all the information we want to include more readily available.
This tries to clarify the fact that the branches must be remote and the syntax
for specifying them as globs.
Cc @yuja, https://github.com/martinvonz/jj/pull/2625#discussion_r1423379351
Here is the result (excerpt):
```
$ jj branch track --help
Start tracking given remote branches
A tracking remote branch will be imported as a local branch of the same name. Changes to it
will propagate to the existing local branch on future pulls.
Usage: jj branch track [OPTIONS] <BRANCH@REMOTE>...
Arguments:
<BRANCH@REMOTE>...
Remote branches to track
By default, the specified name matches exactly. Use `glob:` prefix to select
branches by wildcard pattern. For details, see
https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.
Examples: branch@remote, glob:main@*, glob:jjfan-*@upstream
```
default_index_store.rs is relatively big, and it contains types and impls in
arbitrary order. Let's split them into sub modules. After everything moved,
mod.rs will only contain tests.
This prints a hint about using `jj new <first conflicted commit>` and
`jj squash` to resolve conflicts. The hint is printed whenever there
are new or resolved conflicts.
I hope this hint will be useful especially for new users so they know
which commit to resolve conflicts in first. It may not be obvious that
they should start with the bottommost one. I hope the hint will also
be useful for more more experienced user by letting them just copy the
printed command without first running `jj log` to find the right
commit..
When e.g. `jj rebase` results in new conflicts, it's useful for the
user to learn about that without having to run `jj log` right
after. This patch adds reporting of new conflicts created by an
operation. It also add reporting of conflicts that were resolved or
abandoned by the operation.
There was no measurable performance impact when rebasing a single
commit in the Linux kernel repo.
Before, an absolute path would be saved in the git_target file if .git is a
symlink. That's not wrong, but seemed a bit weird. Let's consolidate the
behavior across .git file types.
Apparently, libgit2 doesn't deduce "core.bare" config from the directory name,
but gitoxide implements it correctly. So we shouldn't blindly canonicalize
the Git repository path. Fortunately, the saved git_target path isn't a fully-
canonicalized form (unless user explicitly sepcified "--git-repo ./.git"), so
we don't need a hack to remap git_target back to the symlink path.
is_colocated_git_workspace() is adjusted since the git_workdir is no longer
resolved from the fully-canonicalized repo path, at least in our code. Still we
have the ".git/.." fallback because test_init_git_colocated_symlink_gitlink()
would otherwise fail. I haven't figured out why, and the test might be actually
wrong compared to the git CLI behavior, but let's not change that for now.
Fixes#2668
A git repo created by the "repo" tool doesn't have core.base set, which means
the "bare"-ness relies on the directory name. Gitoxide appears to parse it
correctly, whereas libgit2 doesn't. That's why the symlinked .git repo is no
longer processed as a colocated repo.
#2668
This adds an initial `jj util gc` command, which simply calls `git gc`
when using the Git backend. That should already be useful in
non-colocated repos because it's not obvious how to GC (repack) such
repos. In my own jj repo, it shrunk `.jj/repo/store/` from 2.4 GiB to
780 MiB, and `jj log --ignore-working-copy` was sped up from 157 ms to
86 ms.
I haven't added any tests because the functionality depends on having
`git` binary on the PATH, which we don't yet depend on anywhere
else. I think we'll still be able to test much of the future parts of
garbage collection without a `git` binary because the interesting
parts are about manipulating the Git repo before calling `git gc` on
it.
See comments inline for details. Cc #2600.
In particular, I wanted to make sure these behaviors are not affected by #2646.
They don't seem to be.
The tests ended up weirder than expected because of
https://github.com/martinvonz/jj/issues/2600#issuecomment-1835418824. Even
though, right now, the behavior of tests is unaffected by that issue, the
*expected* behavior is different.
Branches move around a little confusigly with `abandon`. We do want to keep
them, to test their behavior, but we can show the change id to make things
clearer.
Each instance of the enum represents a single command, so singular
`*Command` seems better. That also seems to match the examples in
clap's documentation.
Note that one of the new tests panics; this is a newly discovered bug.
In Git, a commit's direct parent is allowed to also be an indirect ancestor
at the same time. `jj` currently tries to prevent this situation, but does
allow it. The correctness of `rebase -r A -d descendant_of_A` currently depends
on this jj-specific behavior; we should change that.
Cc #2600
Allowing `jj init --git` in an existing Git repo creates a second Git
store in `.jj/repo/store/git`, totally disconnected from the existing
Git store. This will only produce extremely confusing bugs for users,
since any operations they make in Git will *not* be reflected in the
jj repo.
This enables cheap str-to-RepoPath cast, which is useful when sorting and
filtering a large Vec<(String, _)> list by using matcher for example. It
will also eliminate temporary allocation by repo_path.parent().
This follows up on 3967f63 (see that commit's description for more
motivation) and e79c8b6.
In a discussion linked below, it was decided that forbidding `-r --skip-empty`
entirely is preferable to the mixed behavior introduced in 3967f63.
3967f637dc (commitcomment-133539911)
This follows up on @matts1 's #2609.
We still allow the `-r` commit to become empty. I would be more comfortable if
there was a test for that, but I haven't done that (yet?) and it seems pretty
safe. If that's a problem, I'm happy to forbid `-r --skip-empty` entirely,
since it is far less useful than `-s --skip-empty` or `-b --skip-empty`.
I think it is undesired to abandon emptied descendants. As far as descendants
of `A` are concerned, `jj rebase -r A` should be equivalent to `jj abandon A`,
and `jj abandon` does not remove emptied commits. It also doesn't seem very
useful to do that, since I think descendant commits of an abandoned (or moved
with `-r`) commit only become empty in pathological cases.
Additionally, if we did want -r to empty descendants of `A`, we'd have to add
thorough tests and possibly improve the algorithm. I want to refactor `rebase
-r` and add features to it, and having to consider cases of commits becoming
abandoned makes everything harder.
For example, if we have
```
root -> A -> B -> C
```
and `jj rebase -r A -d C` empties commit `B` (or `C`), I do not know whether
the current algorithm will work correctly. It seems possible that it would, but
that depends on the fact that empty merge commits are not abandoned for
descendants. That seems dangerous to rely on without tests.
I hope (but can't promise) that in the near future, making DescendantRebaser
return more information should help make it possible to create such
functionality in a more robust way. I am likely to attempt this as part of
implementing `-r --after`.
Adress the post-merge comments from #2486, which found a doc comment
inaccurate and to not blindly ignore `-j 0` which would've worked until now.
I've also reduced the default `jobs` size to one, as it's user-visible configuration
which determines how many processes should run.
Thanks to @necauqua the controversial `unsafe` usage was already removed.
I've omitted to change `revisions` from an Vec to a RevisonArg for the moment,
as I will keep working on the file anyway.
If the existing git repo contains local and remote branches of the same name,
one of the remote branches is probably a tracking remote branch. Let's show
a hint how to set up tracking branches. The tracking state could be derived
from .git/config, but doing that automatically might cause another issue like
#1862, which could have been mitigated by git.auto-local-branch = false.
`RevsetExpression::resolve()` is meant for programmatically created
expressions. In particular, it may not contain symbols. Let's try to
clarify that by renaming the function and documenting it.
Repeating these is a no-op. This allows:
```shell
jj new -r a -r b # Equivalent to jj new a b
jj new --before a --before b # Equivalent to jj new a b --before
```
I keep typing the latter and getting an annoying error.
Follows up on 13c93d5270.
The information I added is explained in that commit's description, but
I feel like it could reduce confusion for future readers of the code.
Since this is the error to spawn (or wait) process, command arguments aren't
important. Let's make that clear by not showing full command string.
#2614
The `scm-record` library comments say that the `file_mode` is:
> The Unix file mode of the file (before any changes), if available.
This reverts commit ffd6884 and fixes#2591 and #2548.
We need to .collect_vec() the parents iterator to temporary buffer since the
borrowed iterator can't be returned back to the dag_walk functions. Another
option is to clone op_store and parent ids to remove &self lifetime from the
iterator, but that also means a temporary Vec is created.
GitBackend will use it to configure gix::Repository. I think UserSettings
is generally useful to pass store-specific parameters, so I've updated all
factory functions.
I'll make it propagate OpStoreError, but OpStoreError is quite different
from the existing StaleWorkingCopyError. I think this error isn't actually
an "error" but a description of the working copy state.
Per discussion in https://github.com/martinvonz/jj/discussions/2555. I'm
okay with either way, but it's confusing if we had "branch create" and
"branch set" and both of these could create a new branch.
Renamed `description_template_for_commit` to
`description_template_for_describe` since it's only used in
`cmd_describe`.
Renamed `description_template_for_cmd_split` to
`description_template_for_commit` and modified to accomodate empty
`intro` argument.
Fixes#2439.
We have a few places where we have a `MergedTreeValue` and need to
read the data associated with it so we can write to the working copy
or include it in a diff. Let's extract some of that shared logic to a
function so we can reuse it. I plan to use it for reading file
contents in advance while streaming a diff in `local_working_copy`
soon (and probably in `jj diff` thereafter), but I think it seems like
an improvement on its own.
Remove a couple of unnecessary unsafes:
- The NonZeroUsize is a constant where the unwrap will optimize away
anyway and we don't have an unsafe without any good reason there :)
- The other two were simply not needed, lifetimes worked fine, maybe
Rust became better since that code was written? NLL? Anyway, they're
gone now
As discussed in Discord, it's less useful if remote_branches() included
Git-tracking branches. Users wouldn't consider the backing Git repo as
a remote.
We could allow explicit 'remote_branches(remote=exact:"git")' query by changing
the default remote pattern to something like 'remote=~exact:"git"'. I don't
know which will be better overall, but we don't have support for negative
patterns anyway.
Since the concurrent diff algorithm is significantly slower when using
the Git backend, I think we'll have to use switch between the two
algorithms depending on backend. Even if the concurrent version always
performed as well as the sequential version, exactly how concurrent it
should be probably still depends on the backend. This commit therefore
adds a function to the `Backend` trait, so each backend can say how
much concurrency they deal well with. I then use that number for
choosing between the sequential and concurrent versions in
`MergedTree::diff_stream()`, and also to decide the number of
concurrent reads to do in the concurrent version.
