The dependabot refused to update some dependencies anyway. Maybe it
conservatively checks if all intra dependencies meet a certain version?
```
updater | 2023/12/15 15:56:45 INFO <job_762807265> No update possible for cargo_metadata 0.17.0
updater | 2023/12/15 15:56:54 INFO <job_762807265> No update possible for crossterm 0.26.1
updater | 2023/12/15 15:57:04 INFO <job_762807265> No update possible for itertools 0.11.0
updater | 2023/12/15 15:57:16 INFO <job_762807265> No update possible for zstd 0.12.4
updater | 2023/12/15 15:57:16 INFO <job_762807265> No update possible for jj-cli 0.12.0
updater | 2023/12/15 15:57:27 INFO <job_762807265> No update possible for toml_edit 0.19.15
updater | 2023/12/15 15:57:38 INFO <job_762807265> No update possible for prost-build 0.11.9
updater | 2023/12/15 15:57:49 INFO <job_762807265> No update possible for prost 0.11.9
```
backout of commit 58744d9573
Just a minor cleanup to remove lifetime parameter from the types. I tried to
reimplement them by using itertools, but I couldn't find a simple way to
encode short-circuiting at the end of either left or right iterator.
We'll probably need a better abstraction, but a separate method is good
enough to remove unsafe code from ReadonlyRepo.
I'm not sure if this is feasible for the other backends, but I guess there
would be less lifetimed variables than DefaultReadonlyIndex.
The idea is that InternalRevset will store a 'static boilerplate function that
borrows an 'index passed by function argument. This way, we can abstract the
index type over Arc<T> and &T without introducing too much generics.
I noticed some cargo dependencies aren't caught by the dependabot. For example,
there are gix updates, but the dependabot somehow thinks it's not possible to
update.
```
updater | 2023/12/14 15:57:52 INFO <job_762380319> Checking if gix 0.55.2 needs updating
proxy | 2023/12/14 15:57:52 [063] GET https://crates.io:443/api/v1/crates/gix
proxy | 2023/12/14 15:57:52 [063] 200 https://crates.io:443/api/v1/crates/gix
updater | 2023/12/14 15:57:53 INFO <job_762380319> Latest version is 0.56.0
...
updater | 2023/12/14 15:58:00 INFO <job_762380319> Requirements to unlock update_not_possible
updater | 2023/12/14 15:58:00 INFO <job_762380319> Requirements update strategy bump_versions
updater | 2023/12/14 15:58:00 INFO <job_762380319> No update possible for gix 0.55.2
```
I don't know what's wrong, but let's try without the grouped updates as it was
working before.
FWIW, this issue looks similar:
https://github.com/dependabot/dependabot-core/issues/7896
I don't know why the dependabot didn't catch this, but there are things to
fix manually. EntryMode was changed to a u16 wrapper, and the enum was renamed
to EntryKind. Other than that, I don't find anything breaking our codebase.
Perhaps, this is the most controversial part. It could be moved to new
"segment" module (or something like "common"), but I think IndexSegment can be
considered a trait that enables the CompositeIndex abstraction.
Added pub(super) or pub where needed. I won't implement accessor methods on
IndexPositionByGeneration and IndexPosition as they are purely value types,
and protecting the inner values wouldn't make sense.
It seems better to have the caller pass the transaction description
when we finish the transaction than when we start it. That way we have
all the information we want to include more readily available.
Previously, the function relied on both the `self.parent_mapping` and
`self.rebased`. If `(A,B)` was in `parent_mapping` and `(B,C)` was in `rebased`,
`new_parents` would map `A` to `C`.
Now, `self.rebased` is ignored by `new_parents`. In the same situation,
DescendantRebaser is changed so that both `(A,B)` and `(B,C)` are in
`parent_mapping` before. `new_parents` now applies `parent_mapping` repeatedly,
and will map `A` to `C` in this situation.
## Cons
- The semantics are changed; `new_parents` now panics if `self.parent_mapping`
contain cycles. AFAICT, such cycles never happen in `jj` anyway, except for
one test that I had to fix. I think it's a sensible restriction to live with;
if you do want to swap children of two commits, you can call
`rebase_descendants` twice.
## Pros
- I find the new logic much easier to reason about. I plan to extract it into a
function, to be used in refactors for `jj rebase -r` and `jj new --after`. It
will make it much easier to have a correct implementation of `jj rebase -r
--after`, even when rebasing onto a descendant.
- The de-duplication is no longer O(n^2). I tried to keep the common case fast.
## Alternatives
- We could make `jj rebase` and `jj new` use a separate function with the
algorithm shown here, without changing DescendantRebaser. I believe that the new
algorithm makes DescendatRebaser easier to understand, though, and it feels more
elegant to reduce code duplication.
- The de-duplication optimization here is independent of other changes, and
could be used on its own.
into_segment() could be added instead of save_in(), but I decided to wrap
save_in(). save_in() may squash ancestor files, so it could be considered an
index-level operation.
This tries to clarify the fact that the branches must be remote and the syntax
for specifying them as globs.
Cc @yuja, https://github.com/martinvonz/jj/pull/2625#discussion_r1423379351
Here is the result (excerpt):
```
$ jj branch track --help
Start tracking given remote branches
A tracking remote branch will be imported as a local branch of the same name. Changes to it
will propagate to the existing local branch on future pulls.
Usage: jj branch track [OPTIONS] <BRANCH@REMOTE>...
Arguments:
<BRANCH@REMOTE>...
Remote branches to track
By default, the specified name matches exactly. Use `glob:` prefix to select
branches by wildcard pattern. For details, see
https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.
Examples: branch@remote, glob:main@*, glob:jjfan-*@upstream
```
default_index_store.rs is relatively big, and it contains types and impls in
arbitrary order. Let's split them into sub modules. After everything moved,
mod.rs will only contain tests.
