If a submodule was created in a commit C on a remote repo, switching from any
commit after C to any commit before C (eg. `jj new C-`) will result in jj
starting to track the files introduced in the submodule.
This issue has popped up very frequently for chromium developers, who
get issues when attempting to check out an older version of chromium.
Fixes#4349
Delete the dead reference to bwb's cultivate which no longer is actively worked on since
in the mean time ersc was founded. Also sort the links in the doc.
Our detection of stale working copy is based on the tree id since a
long time ago, at least since Feb 2022 (e098c01935) depending on how
you count. Since Sep 2022 (443e73f346), we keep the last operation
recorded in the working copy up to date. However, we don't update it
when the tree id matches. That's inconsistent, so I think we should
always keep it up to date. This patch fixes that.
Thanks to @kevincliao for spotting this. We noticed this at Google
because it meant that we sometimes didn't notice the new operation id
in our distributed file system, which led to the machine creating
divergent operations. (The machine is supposed to detect operations
recorded in the operation log but this is sometimes flaky for
unrelated reasons.)
This adds a test case of a scenario we sometimes run into at Google
with our distributed file system. It can happen that two machines
accessing the distributed file system do the same snapshotting but one
machine doesn't see the other one's operation due to cache
invalidation bugs.
The primary benefit of this change is that it splits
"lines_added()" and "lines_removed()" into separate fields,
which will be useful for tools.
Many tools use "status()", "lines_added()", "lines_removed()",
"source()" and "target()" to show useful information about
every file modified in a commit.
The existing diff stats summary shows only the combined
number of lines modified, along with a "percentage" representation
of line additions vs. deletions. This is lossy and not
useful for tools, since it is impossible to arrive at
the exact number of lines added and deleted.
The reload-to-HEAD logic added in 7a296ca1 to fix a race condition was
breaking "workspace update-stale" by reloading the repo to HEAD before
snapshotting, even though recovery intentionally loads at an old
operation.
Fix by adding a flag that skips the reload when recovering from a stale
working copy.
Add a test that reproduces the bug where "workspace update-stale" fails
in colocated repos with the same "working copy is stale" error it's
supposed to fix.
Since the specified patterns are no longer guaranteed to match at least one
remote branch, the default (remote) branch is taken into account if exact
patterns match nothing. I think this is better because `-b glob:*` is now
identical to the default.
The warning message is slightly adjusted to be similar to the other "no
matching" warnings. I don't think the new formatting is better, but it's not
worse either.
We no longer need AdvanceBookmarksSettings type because the parsed result can be
a single StringMatcher. This patch also adds the defaults to config/misc.toml to
simplify error handling.
"jj bookmark move" no longer shows a warning for named bookmarks not pointing to
the --from revisions. I think that's okay. `move --from=REV 'PATTERN ~ main'` is
a valid use case, and "main" shouldn't be warned.
This prepares for migration to parse_union_name_patterns(). find_bookmarks*()
will be inlined, and new helper function for unmatched warnings will be added.
In order to write config settings of tools for jj fix, you needed
information that were split in the `jj fix --help` text and
`jj help -k config` (or the respective web-pages).
Move every bit of information that is important to know to write
`jj fix` configurations in the config page. This avoid to have to
maintain the information up-to-date in two places.
Organize the help text of `jj fix` with several chapters.
Users cannot rebase and request both --onto and --insert-before: this is
enforced by clap as well as panics in compute_commit_location. Remove the
unnecessary validation.
- Wrapped all lines to 80 columns (using `concat()` where able).
- Dedented all TOML values.
- Put all close parentheses on their own line (looks more balanced).
- Added trailing commas for variadic functions such as `concat()` and
`separate()`.
- Fixed "(redacted)" bug for `format_operation_redacted(op)`.
`test_init_load_non_utf8_path` and
`test_init_additional_workspace_non_utf8_path` now early-return on
strict UTF-8 filesystems because there's no way to report a test as
"skipped" at runtime.
Closes https://github.com/jj-vcs/jj/issues/8118
After filing https://github.com/jj-vcs/jj/issues/7685 I ran some perf traces to try to understand just what was taking so long during these slow operations. The changes in this PR reduces clone time for my large repo from about 10 minutes to 4m30s.
You can see my thought process in the comments of the above task but to summarize:
During checkout we check files/directories being created to ensure that we are not attempting to write to a reserved directory (`.jj/`, `.git/`). `same_file::is_same_file()` is an expensive check that invokes _at least 4_ syscalls when called in a naive manner (`open()` and `close()` for each path -- plus possibly more for getting file info? I haven't counted).
There are a few optimization gaps here that are causing significant slowdowns. The following checklist reflects what I've optimized in this PR, and what still remains:
- [x] `create_parent_dirs` will be called for each file/directory and for each parent dir in a path **try to create it and check if the dir is an illegal name via `reject_reserved_existing_path()`**. There is no caching of directories which have already been created.
- [ ] `reject_reserved_existing` calls `same_file::is_same_file()` in a loop for all reserved names, but the path which _has maybe been created_ isn't going to change, so its handle could be cached.
- [ ] `can_create_new_file` attempts to create the file then just uses the result as an indicator of whether or not the file is created. However, since we _have a `File`_ that `File` can be directly converted to a `same_file::Handle` and avoid a syscall that currently occurs when converting the `Path` to a `same_file::Handle`.
- [ ] `can_create_new_file` deletes the file immediately after. There's probably an opportunity here to **not** delete the file and re-use it for file write operations.
- [ ] Say we have 1000 files in `foo/`. For each file that's written, `reject_reserved_existing` is going to make at least `RESERVED_DIR_NAMES.len() * 1000` syscalls constructing `foo/{reserved_dir_name}` paths, testing their existence, etc. Maybe `jj` might create this dir? But I don't think that should ever happen -- so why not cache the handle **if** it's created and use a lookup table in `reject_reserved_existing` to only conduct these types of checks if the handle is resolved? Or alternatively cache that the file _does not_ exist after the first check.
Here are some perf traces of running a `jj git clone` of my large repo before:
Release: https://share.firefox.dev/4oiSTBw
Debug: https://share.firefox.dev/4qmJBX1
And after:
Release: https://share.firefox.dev/4nK66mH
Debug: https://share.firefox.dev/470W1ed
As a follow-up to #8115, this moves all references in the codebase to use the new website.
I didn't update the older CHANGELOG entries because I figured they're intended
to be immutable.
