This backs out commit 89d57ffb29577c99f0f5187b76bff369f19c5886.
This is causing a CI failure because we can't build musl binaries,
presumably because the rust-toolchain file overriding the chosen
musl toolchain for some reason. Backout until we can reapply
a proper fix.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Before, "jj config get"/"list" and .get() functions processed inline tables as
tables (or directories in filesystem analogy), whereas "set"/"unset" processed
ones as values (or files.) This patch makes all commands and functions process
inline tables as values. We rarely use the inline table syntax, and it's very
hard to pack many (unrelated) values into an inline table. TOML doesn't allow
newlines between { .. }. Our common use case is to define color styles, which
wouldn't be meant to inherit attributes from the default settings.
The default pager setting is flattened in case user overrides pager.env without
changing the command args.
Follow-up from discussion at https://discord.com/channels/968932220549103686/1288926971719323762
I don't think we achieved consensus in that thread. We could use `stable` or `nightly` here instead if we prefer. Note that user `rustup` overrides are still respected in the presence of a `rust-toolchain.toml`.
Some Git merge drivers can partially resolve conflicts, leaving some
conflict markers in the output file. In that case, they exit with a code
between 1 and 127 to indicate that there was a conflict remaining in the
file (since Git uses a shell to run the merge drivers, and shells often
use exit codes above 127 for special meanings such as exiting due to a
signal):
https://git-scm.com/docs/gitattributes#_defining_a_custom_merge_driver
We should support this convention as well, since it will allow many Git
merge drivers to be used with Jujutsu, but we don't run our merge tools
through a shell, so there is no reason to treat exit codes 1 through 127
specially. Instead, we let the user specify which exact exit codes
should indicate conflicts. This is also better for cross-platform
support, since Windows may use different exit codes than Linux for
instance.
I left the "merge-tool-edits-conflict-markers" option unchanged,
since removing it would likely break some existing configurations. It
also seems like it could be useful to have a merge tool use the default
conflict markers instead of requiring the conflict marker style to
always be set for the merge tool (e.g. if a merge tool allows the user
to manually edit the conflicts).
The current docs for conflict markers start out by introducing Git
"diff3" conflict markers, and then discussing how Jujutsu's conflict
markers are different from Git's. I don't think this is the best way to
explain it, because it requires the reader to first understand Git's
conflict markers before they go on to learn Jujutsu's conflict markers.
Instead, I think it's better to explain the conflict markers from
scratch with a more detailed example so that we don't assume any
particular knowledge of Git.
This structure also works better with the new config option, since we
can talk about the default option first, and then go on to explain
alternatives later.
Use `jj new && jj undo` instead of `jj new @-` at the end of converting to a
co-located repository, because the latter "stashes" newly added working copy
changes into a sibling commit.
See also: https://github.com/martinvonz/jj/discussions/4945
Signed-off-by: Tim Janik <timj@gnu.org>
Our docs are built with MkDocs, which requires Python and several deps.
Previously those deps were managed with Poetry, which is also written in Python.
This commit replaces Poetry with `uv`, a Rust-based Python
project/package manager, and thus removes several steps from the docs
build process.
Before:
<install Python>
<install pipx>
pipx install poetry
poetry install
poetry run -- mkdocs serve
After:
<install uv>
uv run mkdocs serve
If you have multiple remotes to push to, you might want to keep some changes
(such as security patches) in your private fork. Git CLI has one upstream remote
per branch, but jj supports multiple tracking remotes, and therefore "jj git
push" can start tracking new remotes automatically.
This patch makes new bookmarks not eligible for push by default. I considered
adding a warning, but it's not always possible to interrupt the push shortly
after a warning is emitted.
--all implies --allow-new because otherwise it's equivalent to --tracked. It's
also easier to write a conflict rule with --all/--deleted/--tracked than with
two of them.
-c/--change doesn't require --allow-new because it is the flag to create new
tracking bookmark.
#1278
This can be used to find the fork point (best common ancestors) of a
revset with an arbitrary number of commits, which cannot be expressed
currently in the revset language.
It was not clear if users should activate both sets of completions if they
wanted the dynamic ones.
The shell commands for activating the dynamic completions are aligned with the
static version. Users can choose / are responsible themselves to add the
activation to their shell config if they want them in every shell instance.
For fish specifically, `script | source` is more idiomatic than
`source (script | psub)`.
* Suggested `watch --color` as recommended by @ilyagr
* Answered monitoring `jj log` with watch and TUIs
* Minor wording fix.
* Adjusted watch(1) and hwatch links as suggested by @ilyagr
Signed-off-by: Tim Janik <timj@gnu.org>
I think most people would benefit from trying both an internal and an
external merge tool.
I was also considering mentioning `kdiff3` or `diffedit3` more heavily.
For `kdiff3`, I find its diff editing interface very confusing and I don't know of anybody who happily uses it as a diff
editor. For `diffedit3`, I'm not very objective.
I don't think recommending KDIff3 for diff editing is good advice in
most cases (as opposed to merge conflict resolution, for which KDiff3 is
very good). OTOH, trying Meld for diff editing is a good idea for many
people.
Historically, this part of the docs uses KDiff3 because it was written
when `meld` was the default and `:builtin` did not exist.
We only explained that working copies can become stale when updating a
commit from another workspace, but there are other cases too. I also
tried to better explain what the state actually means.
We had documented that we support `git.auto-local-bookmark` but we
don't. The documentation has been incorrect since d9c68e08b1a5. This
patch fixes it by adding support for `git.auto-local-bookmark` with
fallback to the old/current `git.auto-local-branch`.
.
This part of the git-comparison table was implying you need to manually
check and clear staged changes in order to only update the previous
commit's message. That isn't the case, though. As mentioned in the
`git-commit` documentation [1], this can be directly achieved by using
the `--only` flag with `--amend`:
> If this option is specified together with --amend, then no paths need
> to be specified, which can be used to amend the last commit without
> committing changes that have already been staged.
[1]: https://git-scm.com/docs/git-commit#Documentation/git-commit.txt--o
The current instructions ask the reader to convert the merge commit into
a single-parent commit, then create a new merge.
It is probably simpler to follow instructions for inserting a new commit
before the merge commit.
