While divergence is talked about in the documentation, few places actually
mention how divergent changes are displayed. I've added such notes to the help
out put of `jj log`, the glossary, and added an example to the guide we have on
divergence.
Fixes#6365
The main reason for this change is that we now give variables different names
based on their types. This helps avoid confusion and makes intent clearer.
However, the type name `FileExecutableFlag` doesn't have a good shortening
(`file_exec_flag` is annoyingly long), so I also renamed the type to something
shorter, which makes the code more legible: easier to mentally parse and
quicker to type.
I removed `File` from the name both for length and because it doesn't really
help distinguish from the executable field in `TreeValue` (because that field
is nested under `TreeValue::File`). Instead, in the upcoming commits I update
comments to consistently use the terms 'on-disk' and 'in-repo' to respectively
refer to the fields in the `FileState` and `TreeValue` structs, which I find
is better for keeping the difference clear in my head.
I went with `Bit` in the new name just because I'm already changing it and I
prefer `exec_bit` slightly over `exec_flag` as the variable name.
The default patterns are still saved to and loaded from .git/config. Maybe we
can add default fetch patterns to jj's configuration, but I'm not sure whether
we should deprecate .git/config fallback.
This test didn't work because add_commit_to_branch() inserts refs/heads/ prefix
internally. There were no branches matching the refspecs in the remote, and just
unborn "main" existed.
Since we don't care for auto tracking nor auto import/export in this test, I
also disabled these features to make the test more predictable.
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
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.
