The idea is that we don't have to reload parent files as we already have the
chain of the parent segments. The resulting readonly index will be constructed
from the loaded parent segments + local entries blob.
I thought IndexLoadError and DefaultIndexStoreError would represent "load" and
"store" failures respectively, but they aren't. Actually, DefaultIndexStoreError
is the store-level error, and IndexLoadError should be wrapped in it.
Make it clearer what the command does, make the error message when the file is
not ignored less of a surprise.
Also, I think it's nice to mention `.git/info/exclude`, since the path is
not trivial to remember.
Since OpStoreError can also include io::Error, it doesn't make much sense to
have Io variant at this level. Let's split it to context-specific errors, and
extract helper method that maps io::Error.
As far as I can see in the chat, there's no objection to changing the default,
and git.auto-local-branch = false is generally preferred.
docs/branches.md isn't updated as it would otherwise conflict with #2625. I
think the "Remotes" section will need a non-trivial rewrite.
#1136, #1862
PersistError is basically a pair of io::Error and NamedTempFile instance. It's
unlikely that we would want to propagate the open file instance to the CLI
error handler, leaving the temporary file alive.
This is really a simple change that does the following in a transaction:
* Set the new branch name to point to the same commit as the old branch name.
* Set the old branch name to point to no commit (hence deleting the old name).
Before it starts, it confirms that the new branch name is not already in use.
I originally thought this would be unavoidable, but I was wrong. "jj git clone"
doesn't implicitly create any local branch if git.auto-local-branch is off, and
that's fine because the detached HEAD state is normal in jj.
That being said, Git users would expect that the main/master branch exists.
Since importing the default branch is harmless, let's create and track it no
matter if git.auto-local-branch is off.
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.
