I'm going to move lock_git_import_export() there so we don't have to reload the
head operation after acquiring the lock. This patch clarifies that
may_snapshot_working_copy is set to self.is_working_copy_writable().
This partially restores the old behavior from 36f4f09be4 "cli: create mutable
working-copy commit only when needed". Since an immutable wc behaves weirdly,
it should be better to avoid creating such state as possible.
Since snapshot_working_copy() cannot use the finish_transaction() helper, we
need to manually export changes to Git. recover_stale_working_copy() now
acquires the Git import/export lock for the first snapshot, which seems more
correct.
Fixes#9827
This is all prep work to make merge_operations non-recursive, because at
Google we are sometimes seeing stack overflow in merge_operations due to
very large (merge_operations) stack frames.
Add a core template type for filesystem paths backed by `PathBuf`.
`FsPath` renders native path bytes directly, so templates can print
paths that are not valid UTF-8. It also provides `.absolute()` and
`.relative()` methods for templates that need to choose between
absolute paths and paths relative to the command's current working
directory.
`json()` uses the existing `PathBuf` serialization behavior. This keeps
common UTF-8 paths as ordinary JSON strings, while non-UTF-8 paths
produce the same serialization error as `PathBuf`.
Pass the command's current working directory through template languages
so `.relative()` is evaluated against the directory the command is
acting from, not `std::env::current_dir()`.
`Option<FsPath>` follows the existing optional-value truthiness
pattern: unset values are false, and set values are true.
Removed some in #9804, but a decision was made to prefer trailing
periods instead of not having them. Updated the style guide to reflect
this decision.
Did a search for `writeln!` and checked that each one ended with a
period or was printing some interpolated value. `Err()` and
`tx.finish()` calls were left alone.
Some users accidentally type jj multiple times, which causes an error.
One solution in use is to define an alias `jj = []`, which makes the
command `jj jj ...` work as if jj was typed only once. However, typing
only `jj jj` didn't work. It still caused an error, instead of using
the default command like `jj`. This is because the default command was
resolved before any aliases. By resolving the default command during the
alias-resolution loop, the above example works as intended.
Noticed this when I did a `jj git fetch` and got:
```
Updated 10 rewritten commits.
Rebased 1 descendant commits
```
Basically did a regex search for `commits\."`, so I might have missed
messages with different formats.
Fixes an issue where remote names with special characters like 'foo@bar' couldn't be properly added as bookmarks using the hints. Escaping the names using shlex::try_quote fixes it.
When renaming or removing a remote that the trunk() alias references,
finish_transaction() would warn about the broken alias because the
in-memory revset alias still pointed to the old remote name. The config
file was only updated after the transaction finished.
Fix this by:
1. Moving the repo config update (rename_remote_in_repo_config /
remove_remote_from_repo_config) to before tx.finish(), so the
persistent trunk() alias is fixed before the next command loads it.
2. Removing the trunk() resolution check from finish_transaction()
entirely — the workspace_helper() check at command startup already
covers broken trunk() aliases.
The previous recursion detection simply checked for repeated alias
expansions. This is simple and incorrect only in rare cases, where
repeated alias expansion is desired.
Intuitively, `aliases.jj = []` should be able to solve the "jj jj jj"
problem, where users accidentally type "jj" multiple times (rarely, but
sometimes, more than twice). Blocking repeated alias expansion prevents
the empty alias from being a general solution to that problem.
For non-empty aliases, a possible use case could be to compose
configuration overrides on the command line using the `--config` flag,
but using aliases to make it convenient to type spontaneously.
Commands like "jj git fetch"/"import" can update immutable commits to reflect
the remote changes. When this happens, we should avoid rebasing their immutable
descendants.
I also updated the doc comment for transform_commits(), which already supports
disconnected ranges. Because find_descendants_for_rebase() excludes commits
within parent_mappings, the graph isn't always connected (without this patch).
The new changelog entry also covers the changes from 44146561 "git: look for
predecessors also in locally reachable commits".
Allows users to set up system-wide config files, for e.g. multi-user setups,
which has lower precedence than per-user config files, unlike $JJ_CONFIG or
--config-file.
closes jj-vcs#7321
While it's a bit odd that the glob pattern and exact remote symbol arguments are
overloaded, the symbol syntax is undeniably convenient.
`RemoteBookmarkNamePattern` and `Display for StringPattern` have been removed as
they are no longer used.
Closes#9226Closes#9426
Allows AliasesMap to store and retrieve optional descriptions for each
alias. This is a prerequisite for surfacing these descriptions in
shell completions.
The new flag --tag=NAME tracks and pushes new tags in the same way as
--bookmark. Other flags are also updated to include tags, but there are a few
exceptions:
* --all doesn't track and push new tags. Since remote tags are still
experimental, creation of new tracked remote tags should be explicit.
* -rREVSET doesn't push tracked tags yet because there would be non-trivial
implementation changes. This will be addressed separately.
As we have discussed in at least
https://github.com/jj-vcs/jj/pull/8148, the name `.tags()` is not a
good name because it can be assumed to be related to the usual kind of
VCS tags.
This patch adds a global `--no-integrate-operation` flag that prevents
integration/publishing of most operations, including the ones created by
`snapshot_working_copy()` and `finish_transaction()`. The operations
are still created as usual.
We provide `jj op integrate` to manually reintegrate operations created by
commands with this flag enabled.
Closes#2562
Co-authored-by: Martin von Zweigbergk <martinvonz@google.com>
There are two reasons for this:
* It helps understanding why divergence happened to see which
workspace an operation was run from. For example, perhaps an agent
is running in another workspace and it's not obvious from the
operation log which commands it ran without seeing the workspace
name.
* We may want to check that e.g. `jj undo` is run from the same
workspace as the operation it's undoing. We may want to print a
warning otherwise, or maybe we want to skip over operations create
from other workspaces. I'm not sure what's best but having the
workspace recorded at least enables such features.
