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 is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which can produce I/O errors during operation. See #7825 for more
information.
This should make things like accidental `jj abandon ..main` error out
much more quickly on large repos like the one at Google (without first
reading hundreds of millions of commits into memory).
I think we should update other commands in a similar way.
I'm about to add a version of `check_rewritable()` that works on a
revset expression instead of an evaluated revset. This patch prepares
for that by having the `--ignore-immutable` case also evaluate a
revset instead of iterating over the commits looking for the root
commit.
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.
