This is a stripped-down version of cmd_bookmark_set(). Since tags shouldn't
usually be rewritten, I've made it fail on updating existing tags by default.
This will help "jj bookmark track" know whether absent remote ref can be created
for the specified remote. "jj bookmark" subcommands shouldn't depend on
gix::Repository API.
Although we don't have "jj git tag set"/"delete" commands, this fixes weird undo
behavior #6325. The discussion in #6325 is derailed, but there would be another
issue for the "abandon unreachable" behavior.
Fixes#6325
Previously untracking a file with `jj file untrack` would not remove the
file from the git index (intent-to-add), making the output of
`jj status` and `git status` inconsistent.
`jj bisect run --command` splits the argument on spaces, so
e.g. `--command 'cargo test'` will run `cargo` with `test` as
argument. It is hard to pass more complex commands to because we don't
parse e.g. quotes as the shell would (and we wouldn't match the user's
preferred shell even if we did).
This patch deprecates the `--command` argument in favor of positional
arguments, so the user can do things like this:
```
jj bisect run --range ..main -- bash -c 'jj duplicate -r xyz -B @ && cargo test'
```
That will run the tests with the `xyz` change applied.
- Added support for workspace-specific configuration using `jj config` commands.
- Introduced `--workspace` option to `jj config edit`, `jj config set`, and `jj config unset`.
- Workspace configuration file is stored in `.jj/workspace-config.toml` per workspace.
- Simplified workspace path handling logic.
- Updated documentation and test snapshots to reflect new behavior.
This improves flexibility for users working across multiple workspaces.
Co-authored-by: Eidolon <furyhunter600@gmail.com>
Co-authored-by: ase <adam@sandbergericsson.se>
Remote names are potentially sensitive? Unsure, so better to redact them.
For getting the "*": This could have been done without modifying the
Rust side, with e.g. `stringify(bookmark).ends_with("*")`. However, this
feels brittle.
With adding `.synced()` to the template language, bookmark formatting
_could_ be done entirely in templates now. I don't know if that's
desired, so leaving for a potential future commmit.
This follows Git's merge driver interface which makes this information
available using the `%P` variable. It is useful for merge drivers to
adapt their behaviour based on the type of file supplied.
Up until now, trying to get a config value that was an array or a table would fail with an error indicating that only values that can be converted to a string can be displayed. This change fixes that issue by converting arrays and tables into TOML format.
Git-tracking tags will be stored there. I don't have a concrete plan for proper
remote tags support, but I think tags fetched/pushed internally can be recorded
as remote tags.
If a subprocess exits with a nonzero status, we don't need to print out
the fact that it exited with a nonzero status.
I think it is fairly obvious that we should try to match the return code
of the inner process.
In a bit more contention is whether we should print out the error
message at all. I would argue that a command that fails almost always
prints to stderr anyway, and the whole point of `jj util exec` is that
it should go into your aliases and thus the fact that it's an "external"
command should be hidden from the user (see my example above).
```
$ jj upload # "upload" is an alias using jj util exec
<presubmit failures>
Error: presubmits failed
external command exited with 5
<exits with exit status 1>
```
Gerrit's web UI (like jj) recognizes unique ID prefixes, so a reference
like `I1234cdef` in a commit message or a review comment becomes a
hyperlink to the referenced change. Currently, every jj-produced change
begins with `I6a6a6964`, which makes that less useful. This moves the
fixed `6a6a6964` component to the end, so the prefix is unique.
Closes#7500.
This is mostly a revert of dd73b5ab7d. It closes#5374, as feedback on
the issue has shown that many longtime and new users dislike it. Martin
himself also mentioned that he wants to walk back this deprecation.
Co-authored-by: Remo Senekowitsch <remo@buenzli.dev>
This implements the most basic workflow for submitting changes to Gerrit,
through a verb called 'upload'. This verb is chosen to match the gerrit
documentation (https://gerrit-documentation.storage.googleapis.com/Documentation/3.12.1/user-upload.html).
Given a list of revsets (specified by multiple `-r` options), this will parse
the footers of every commit, collect them, insert a `Change-Id` based off the jj change-id (if one doesn't already exist), and then push them into the given remote.
It will then abandon the transaction, thus ensuring that gerrit change-IDs do not appear in jj.
Because the argument is a revset, you may submit entire trees of changes at
once, including multiple trees of independent changes, e.g.
jj gerrit upload -r foo:: -r baz::
Signed-off-by: Austin Seipp <aseipp@pobox.com>
I have no idea if we can change the default, but maybe we can conditionally
disable the same-change rule to get rid of hacks in squash_commits(), etc.?
resolve_file_executable() doesn't respect the Store configuration. I'm not sure
if that's the right choice, but it seemed better to accept duplicated change
than falling back to executable=false.
#6369
The commit builder prepared by `rewriter.reparent()` already updates the
author to the currently configured one in case the author was previously
unset. When the new author is compared to `commit_builder.author()`,
they compare as equal, making it look like the author didn't change.
If that was the only change that would've happened, the commit is not
rewritten at all, meaning the commit author stays unset. This is fixed
by comparing the new author to the actual author of the old commit.
This option affects emptiness of commits, which means indexed changed files can
become stale on configuration change. This problem can also be said for changes
in the diff algorithms, so I don't think we need a logic to invalidate index on
config change.
I have this patch for months, and it seems working good at least for Rust
sources.
Closes#17
As suggested by @PhilipMetzger
The word "grey" is whitelisted because
- we have a contributor of that name
- we use a library that uses "Grey" as a member of an enum
- I refuse to believe "grey" is not US English
