It was requested on Discord once.
The result is almost a tutorial; we could consider actually moving it into the
tutorial and providing a link in the FAQ. That could be done separately.
The `jj` commands outputs are faked in a few, hopefully inconspicuous, ways.
Hopefully, this is not distracting.
Typo in signing.behavior shouldn't be ignored.
The idea is the same as [user] and [operation] tables. It's easier if all
parameters needed to create a commit is parsed by UserSettings constructor.
Another option is to make repo.start_transaction() fail on config error.
It is not needed to gate `jj debug init-local` on an option now that the
command is no longer called `jj init`.
This also includes a separate fixup to #5845 in demos/
The main goal here is so that a completely new user that types in `jj
init` or `jj clone` gets a pointer to the correct command needed to try
out `jj`.
Now that we depend on the `git` executable being available for `jj git
fetch/push` tests, we might as well use it for `jj util gc` tests
too.
I also switched to using the Git backend in
`cli/tests/test_file_track_untrack_commands.rs`, which seemed to be
using the local backend for no good reason.
The gix feature "blocking-network-client" was configured in cd6141693
(cli/tests: add gitoxide helpers, 2025-02-03) most likely because
we needed to clone using gix in tests, but 071e724c1 (cli/tests:
move test_git_colocated_fetch_deleted_or_moved_bookmark to gitoxide,
2025-02-25) changed the test to clone by subprocessing out to system git
(not by using gitoxide, as a cursory read of the commit description may
indicate), meaning that we no longer need that feature.
Therefore, remove that feature.
The warning this suppresses is shown by `mkdocs serve`:
```
INFO - The following pages exist in the docs directory, but are not included in the "nav" configuration:
- paid_contributors.md
```
We can alternatively add that doc to nav.
This will be used to compute the location to place commits from the
`--destination`, `--insert-after`, and `--insert-before` options. This
is used across the `new`, `duplicate`, and `rebase` commands, and can be
used for further commands as well.
The previous implementation of `new --insert-after` excluded children
that were ancestors of the new commit. This was done to avoid creating
cycles in the commit graph. However, this does not align with the
behavior of the `--insert-after` in the other commands, which explicitly
error if inserting a new commit after the given `--insert-after` commits
would create a cycle.
For consistency, and given that the desired behavior can be achieved
using by using `--insert-after` along with `--insert-before`, this
behavior is removed.
After system crash, file contents are often truncated or filled with zeros. If
a file was truncated to empty, it can be decoded successfully and we'll get
cryptic "is a directory" error because of an empty view ID. We should instead
report data corruption with the ID of the corrupted file.
#4423
The consensus about this change, if one ever existed, seems to have dissolved
into two cohorts, one which is happy with the change, and one which thinks we
should move both the bookmark and change id to the child commit instead of
leaving them on the parent.
We may decide to add flags to allow users to choose between the two behaviors,
but there are also other concerns such as where @ should go (parent or child).
Until we agree on a path forward it seems reasonable to delay the breaking
change by disabling it via the config option we added. I don't think it's
necessary to fully revert the code and new tests since we aren't announcing the
option.
#3419
This has bothered me for a while... It's useful to describe the target of the
split command as the "target commit", and it's a little confusing to have a
variable named "commit" in the code when we are dealing with several different
commits in the command.
I think this improves readability by being more precise.
Clearing a sign key would require calling `set_sign_key(None)`, which
makes the API slightly awkward.
Instead, we introduce `clear_sign_key()` and make `set_sign_key()` only
accept a `String`. This makes clearing the sign key explicit.
Co-Authored-By: Yuya Nishihara <yuya@tcha.org>
When signing commits with `jj sign`, one might want to use a workflow
like:
```bash
jj fix && jj sign .. && jj git push
```
Making the default value for `-r`/`--revisions` configurable, will allow
such a workflow.
Co-Authored-By: Yuya Nishihara <yuya@tcha.org>
This will probably mitigate problems of concurrent updates. If two concurrent
processes tried to import + reset HEAD, one of them should fail.
Closes#3754
I think I likely found the issue. zizmor seems OK
with persisting credentials, see
https://github.com/jj-vcs/jj/actions/runs/13559693565/job/37900455060?pr=5820
Both of these workflows run only on commits in `main`,
so this doesn't seem like a huge security hole, but
we could consider other, better solutions in the
future.
Follow up to 78177ff. See #5819 for a failed attempt.
cc @thoughtpolice @neongreen @martinvonz
