We currently don't allow you to create two identical commits. It
results in an internal error. I think we need to allow it. Let's start
by testing the current behavior.
I created these as CLI tests because I want to make sure that `evolog`
and `op diff` get tested, including rendering.
I think if a particular test sets e.g. $JJ_TIMESTAMP, they would
expect it to get used by `run_jj()` but we currently overwrite a few
variables in that method. This patch makes it so we respect all
environment added to the test environment.
I'm going to use this for a test case that attempts to create
identical commits.
Just moments ago, I ran into a case where I wanted to change both the
author and committer of a change. I knew about the new `jj metaedit`
command, but until now that only gave me the ability to update the
author of my change, so the committer would remain the same. My only
other option was to reach for `jj desc ... --reset-author`, which has
a deprecation warning:
Warning: `jj describe --reset-author` is deprecated; use `jj metaedit --update-author` instead
In spite of that warning, this had the desired effect: both the author
and committer were updated.
So I figured I'd help `metaedit` grow these flags so it can be a _true_
replacement for `jj desc --reset-author`.
---
The above all happened before I was kindly informed in Discord
(https://discord.com/channels/968932220549103686/1431315533164314674)
that `jj metaedit --update-committer-timestamp` should do what I was
hoping for, which I had initially disregarded and never tried because
the help text originally said:
This updates the committer date to now, without modifying the committer.
However, after trying it out, I noticed it actually _did_ modify the
committer.
So, I set out to improve the situation by renaming the flag (so it's
not partially-wrong: it does update the committer timestamp, as well as
everything else about the committer) and improving the help text in the
various flags.
---
In no particular order, thanks to:
* obtuse, for informing me that the `--update-committer-timestamp`
flag does what I wanted in the first place
* gaetan, for pointing out that my way of thinking was not quite meshing
with how jj does things (every modification will update the committer)
* Martin, for the new flag name
This new command lets you turn a non colocated git repo into a colocated repo or vice-versa (by using the `jj git colocation enable` and `jj git colocation disable` commands respectively).
These commands simply implement the instructions found in https://github.com/jj-vcs/jj/blob/main/docs/git-compatibility.md#converting-a-repo-into-a-co-located-repo
You can also call `jj git colocation status` to show the current colocation status and `jj colocation` to show a help message (with the list of sub-commands).
This includes the fix for
https://github.com/BurntSushi/ripgrep/issues/3127. The fix let us
optionally allow unclosed character classes in .gitignore files. It is
allowed by default when using the `GitignoreBuilder` (as we do), so we
get the fix without code changes.
I'm planning to try to add conflict labels to `MergedTree` and
`MergedTreeId`, and it will be easier to add them if both are structs
with similar methods. Since we don't support reading/writing legacy
conflicts anymore (as far as I'm aware), I think it should be safe to
delete the `MergedTreeId::Legacy` variant now.
When cloning with the branch option:
- Only the specified branch will be fetched
- The trunk alias is only set if the specified branch happens to be the default branch
- The clone fails if the branch does not exist in the remote
Since we can now update tags internally, local and remote tags may be out of
sync in non-colocated Git repositories. "tags" template should indicate that.
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.
