Colocation is about sharing the working copy between jj and git. It's
less important where the repo is stored. I therefore think we should
not call it "colocated repo". I considered renaming it to "colocated
working copy" but that sounded awkward in many places because we often
talk about the whole workspace (repo + working copy), so "In colocated
workspaces with a very large number of branches or other refs" sounds
better than "In colocated working copies with a very large number of
branches or other refs".
Once we support colocate workspaces in non-main Git worktrees, I think
this rename will be even more relevant because then all those
workspaces share the same repo but only some of them may be colocated.
Undoing a push operation does not undo the effects on the remote.
Bookmarks on the remote will stay in place, but the local repository
will forget about their state. If the bookmarks are subsequently
moved and pushed, that later push will fail, since the bookmarks have
"unexpectedly" moved on the remote. Therefore, add a warning telling
users to run `jj redo` to avoid these complications.
The default remote parameter of remote_bookmarks() will be derived from this
parameter. It doesn't make sense to exclude @git bookmarks if the backend isn't
Git. It's also nice that parsing tests don't depend on the feature flag.
in clap, the visible_aliases, e.g. '[aliases: --after]' are shown at
the very end, which makes it confusing if you're reading from top to
bottom.
aliases are currently omitted entirely from the man pages, making it
confusing to see undocumented aliases being used.
A typical use case is to query bookmarked revisions ignoring auto-generated
bookmarks. `bookmarks() ~ bookmarks(x)` doesn't work because a revision may have
multiple bookmarks. It's also nice that we can document the default of
`remote_bookmarks()` as `remote_bookmarks(remote=~exact:"git")`.
Closes#7665
If we removed 'b lifetime to use locally-constructed StringMatcher in place of
StringPattern, find_matches() would have to return iterator capturing the
argument of higher-rank lifetime. This patch makes the callback function collect
items. The cost of extra allocation wouldn't matter.
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.
- Introduced a few more instances of the existing anti-pattern, `TODO:
indexing error shouldn't be a "BackendError"`. We're tracking this
known issue in #7849.
- Converted `MutableRepo::merge_view` to return a `RepoLoaderError`
instead of a `BackendError`. The only caller, `MutableRepo::merge`,
already returns a `RepoLoaderError`.
- Added three "`fallible_`" iterator helpers to reduce the amount of
noise at `is_ancestor` call sites due to the method now being
fallible. Using these helpers seem to produce code that's a little
more readable than using `process_results` from itertools. One
consideration in this trade-off is that these helpers do not
themselves return iterators: if we find that we need more support for
fallible combinators mid-"chain" of iterator combinators, we might
either want to use `process_results` only in those cases, or switch to
use of `process_results` across the board (in lieu of these new
helpers).
This change was motived by the next Gitoxide version adding an
additional lifetime to `gix::reference::iter::Iter`, which currently
breaks the automated Dependabot upgrade.
I left annonymous lifetime annotations on ref-like types like
`RemoteRefSymbol`.
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.
