commits
It generates numerous warnings that it will stop working once Node 16 is
unsupported. This replaces it by a seemingly equivalent action that
somebody is supporting. I tired this change on
https://github.com/ilyagr/diffedit3/, and it seems to work.
I think it would be better to switch to using
https://github.com/shogo82148/actions-upload-release-asset, which is
recommended at https://github.com/actions/upload-release-asset, but that
would be a slight change to the release process (that action creates a
release when a tag is pushed, we'd probably want it to be for tags
starting with `v`), so I'll let @martinvonz do that.
Ultimately, Martin, since you do the releases, it's entirely up to you
what we do here. For example, you can wait until the next release and
experiment with this PR then.
For API consistency. It wouldn't practically matter unless we want to reuse
.iter_graph() in lazy event-driven GUI context.
I don't see significant performance difference:
- jj-0: original impl with look-ahead IndexEntry<'_> buffer
- jj-1: this patch
With dense graph
```
% hyperfine --sort command --warmup 3 --runs 10 -L bin jj-0,jj-1 \
"target/release-with-debug/{bin} -R ~/mirrors/git --ignore-working-copy log -r.. -T ''"
Benchmark 1: target/release-with-debug/jj-0 -R ~/mirrors/git --ignore-working-copy log -r.. -T ''
Time (mean ± σ): 1.367 s ± 0.008 s [User: 1.261 s, System: 0.105 s]
Range (min … max): 1.357 s … 1.380 s 10 runs
Benchmark 2: target/release-with-debug/jj-1 -R ~/mirrors/git --ignore-working-copy log -r.. -T ''
Time (mean ± σ): 1.344 s ± 0.017 s [User: 1.245 s, System: 0.099 s]
Range (min … max): 1.313 s … 1.369 s 10 runs
Relative speed comparison
1.02 ± 0.01 target/release-with-debug/jj-0 -R ~/mirrors/git --ignore-working-copy log -r.. -T ''
1.00 target/release-with-debug/jj-1 -R ~/mirrors/git --ignore-working-copy log -r.. -T ''
```
With sparse graph
```
% hyperfine --sort command --warmup 3 --runs 10 -L bin jj-0,jj-1 \
"target/release-with-debug/{bin} -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''"
Benchmark 1: target/release-with-debug/jj-0 -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''
Time (mean ± σ): 1.347 s ± 0.017 s [User: 1.216 s, System: 0.130 s]
Range (min … max): 1.321 s … 1.379 s 10 runs
Benchmark 2: target/release-with-debug/jj-1 -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''
Time (mean ± σ): 1.379 s ± 0.023 s [User: 1.238 s, System: 0.140 s]
Range (min … max): 1.328 s … 1.403 s 10 runs
Relative speed comparison
1.00 target/release-with-debug/jj-0 -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''
1.02 ± 0.02 target/release-with-debug/jj-1 -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''
```
Prepares for removing &CompositeIndex from the RevsetGraphIterator struct.
The input iterator will also be changed to position-based.
I've turned self.look_ahead.get().unwrap() into assertion, but it's not super
important here. It's just for sanity that we've mapped missing edges properly.
FWIW, we could say RevsetGraphIterator is an example of iterating *and* testing
membership of the input revset (though the yielded entries are discarded.)
The RevsetGraphIterator type is hidden so that the Iterator trait can be
implemented differently.
In the FAQ question "How do I integrate Jujutsu with Gerrit?", the link
to the glossary entry for "co-located repos" was pointing to the entry
for "change-id".
This drops the trailing period for consistency with other commands,
and rephrases them a bit for consistency between each other.
Bumps the github-dependencies group with 2 updates: [DeterminateSystems/nix-installer-action](https://github.com/determinatesystems/nix-installer-action) and [DeterminateSystems/magic-nix-cache-action](https://github.com/determinatesystems/magic-nix-cache-action).
Updates `DeterminateSystems/nix-installer-action` from 9 to 10
- [Release notes](https://github.com/determinatesystems/nix-installer-action/releases)
- [Commits](https://github.com/determinatesystems/nix-installer-action/compare/cd46bde16ab981b0a7b2dce0574509104543276e...de22e16c4711fca50c816cc9081563429d1cf563)
Updates `DeterminateSystems/magic-nix-cache-action` from 3 to 4
- [Release notes](https://github.com/determinatesystems/magic-nix-cache-action/releases)
- [Commits](https://github.com/determinatesystems/magic-nix-cache-action/compare/eeabdb06718ac63a7021c6132129679a8e22d0c7...fc6aaceb40b9845a02b91e059ec147e78d1b4e41)
---
updated-dependencies:
- dependency-name: DeterminateSystems/nix-installer-action
dependency-type: direct:production
update-type: version-update:semver-major
dependency-group: github-dependencies
- dependency-name: DeterminateSystems/magic-nix-cache-action
dependency-type: direct:production
update-type: version-update:semver-major
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Now you can do e.g. `jj squash --from 'foo+::' --into foo` to squash a
whole series into one commit. It doesn't need to be linear; you can
squash a bunch of siblings into another siblings, for example.
I plan to teach `jj squash --from` to accept a revset as input.
I'm going to teach the function to support combining more than two
descriptions.
For the same reason as the previous commit. Since self.inner.positions()
basically clones the underlying evaluation tree, there is no reason to stick
to &self lifetime. Perhaps, some of the CLI utility can be changed to not
collect() the iterator.
Migrating iter_graph() requires non-trivial changes, so it will be done
separately.
This allows callers to cache the returned function at 'index lifetime. It's
important in templater. It also means the returned function could be 'static
if the index were Arc<_> and we had a trait interface to achieve that.
Option<Box<dyn ..>> is removed since RevWalk is fused.
This makes the whole evaluation tree 'static, and we can freely move it without
keeping the root RevsetImpl object alive.
Perhaps, "Self: 'a" can be replaced with 'static, but let's leave it for now.
It's not technically wrong to store lifetimed object in InternalRevset.
Prepares for dropping &self lifetime from to_predicate_fn(). All predicate
functions could be wrapped as Box::new(PurePredicateFn(Rc::new(f))) instead, but
I don't think the .clone() cost matters.
Bumps the github-dependencies group with 1 update: [actions/checkout](https://github.com/actions/checkout).
Updates `actions/checkout` from 4.1.1 to 4.1.2
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/b4ffde65f46336ab88eb53be808477a3936bae11...9bb56186c3b09b4f86b1c65136769dd318469633)
---
updated-dependencies:
- dependency-name: actions/checkout
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Bumps the cargo-dependencies group with 3 updates: [anyhow](https://github.com/dtolnay/anyhow), [proc-macro2](https://github.com/dtolnay/proc-macro2) and [thiserror](https://github.com/dtolnay/thiserror).
Updates `anyhow` from 1.0.80 to 1.0.81
- [Release notes](https://github.com/dtolnay/anyhow/releases)
- [Commits](https://github.com/dtolnay/anyhow/compare/1.0.80...1.0.81)
Updates `proc-macro2` from 1.0.78 to 1.0.79
- [Release notes](https://github.com/dtolnay/proc-macro2/releases)
- [Commits](https://github.com/dtolnay/proc-macro2/compare/1.0.78...1.0.79)
Updates `thiserror` from 1.0.57 to 1.0.58
- [Release notes](https://github.com/dtolnay/thiserror/releases)
- [Commits](https://github.com/dtolnay/thiserror/compare/1.0.57...1.0.58)
---
updated-dependencies:
- dependency-name: anyhow
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: proc-macro2
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: thiserror
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Perhaps, union/intersection/difference combinators can be moved to the
rev_walk module, but let's think about that later.
Now all source/sink nodes produce/consume IndexPosition, so it doesn't make
sense to keep InternalRevset::entries().
This is the step towards removing &CompositeIndex references from the revset
evaluation tree. The filter input is changed from &IndexEntry to IndexPosition
to simplify the lifetime thingy. We might want to pass around CommitId or
Commit object once it's loaded, but that can be implemented later. I don't
see significant performance difference in revset benches.
This helps to migrate union/intersection/difference iterators to RevWalk.
This serves the same role as templater::Literal. I'm going to add basic
RevWalk adapters so that the revset evaluation tree can be constructed without
capturing the index. EagerRevWalk will help to write tests for these adapters.
Now as default and elided node symbols come from the config, the next logical
step is to use them directly bypassing GraphLog. Note that commands like `jj op
log` and `jj obslog` do not use the elided node symbol at all.
We're early in the release cycle, so let's enable this feature and
test it for a while before the next release.
The `jj log` command had basically no documentation. Let's at least
start adding some.
Per discussion in
https://github.com/martinvonz/jj/discussions/2882. `jj squash` now has
all the functionality.
This was proposed by @Brixy in
https://github.com/martinvonz/jj/discussions/2882 a while ago. There
seems to be pretty strong consensus that it's a good idea.
I've copied the added test cases from `test_move_command.rs`, just
replacing `move` by `squash`, `--to` by `--into`, and deleting the
test of a no-arg invocation (`jj move` fails, `jj squash` does not -
it defaults to squashing into the parent).
Bumps the cargo-dependencies group with 2 updates: [minus](https://github.com/arijit79/minus) and [whoami](https://github.com/ardaku/whoami).
Updates `minus` from 5.5.3 to 5.6.0
- [Changelog](https://github.com/arijit79/minus/blob/main/CHANGELOG.md)
- [Commits](https://github.com/arijit79/minus/compare/v5.5.3...v5.6.0)
Updates `whoami` from 1.5.0 to 1.5.1
- [Changelog](https://github.com/ardaku/whoami/blob/v1/CHANGELOG.md)
- [Commits](https://github.com/ardaku/whoami/compare/v1.5.0...v1.5.1)
---
updated-dependencies:
- dependency-name: minus
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: cargo-dependencies
- dependency-name: whoami
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Just a minor code cleanup. We still need Index for &CompositeIndex because the
type is unsized, and unsized type cannot be converted to another dyn reference.
This helps to eliminate higher-ranked trait bounds from RevWalkRevset and
RevWalk combinators to be added. Since &CompositeIndex is now a real reference,
it can be passed to functions as index: &T.
This helps to migrate CompositeIndex<'_> wrapper to &CompositeIndex. If
the wrapped reference had a lifetimed field, it couldn't be represented as
a trivial reference type.
Since consume_to() checks the bottom position yielded from the source iterator,
it makes sense to add the same check for the cached positions.
This patch makes `jj squash` us the helper I just extracted from `jj
move`. I had a to add a few small features to it for that.
The `test_squash_command.rs` test changed in a few cases where we do a
partial squash. After this patch, we include the rebased child in the
count of rebased descendants. That seems reasonable and consistent
with partial squash/move further than 1 generation.
This is just a little step towards reusing the helper I just extracted
from `jj move`. I had to update `test_immutable_commits.rs` because it
would otherwise fail because of the merge rather than failing because
of the immutable commit.
I'm soon going to make `jj squash` accept either `-r` or
`--from/--to`, which means `-r` will then be optional. This patch
prepares for that already, since it also simplifies the code a little
(and improves it so we warn if the user does `jj squash -r @
nonexistent`).
This matches what we do for `jj squash`, whether it's a
full or partial move.
I didn't add a test since we're planning to deprecate `jj move`, and
this will soon be tested via the `jj squash` tests.
The `destination` variable we use when creating the operation log may
have been replaced earlier in the code. I think this was a regression
when I moved the setting of the description from `start_transaction()`
to `finish_transaction()` a while ago.
We haven't used custom Git commit headers for two main reasons:
1. I don't want commits created by jj to be different from any other
commits. I don't want Git projects to get annoyed by such commit
and reject them.
2. I've been concerned that tools don't know how to handle such
headers, perhaps even resulting in crashes.
The first argument doesn't apply to commits with conflicts because
such commits would never be accepted by a project whether or not they
use custom commit headers. The second argument is less relevant for
conflicted commits because most tools will be confused by such commits
anyway.
Storing conflict information in commit headers means that we can
transfer them via the regular Git wire protocol. We already include
the tree objects nested inside the root-level tree, so they will also
be transferred.
So, let's start by writing the information redundantly to the commit
header and to the existing storage. That way we can roll it back if we
realize there's a problem with using commit headers.
Probably just a bad copy&paste.
Initially we were thinking to have `Revset` return something like
`CachedRevset`:
```
pub trait CachedRevset {
fn iter(&self) -> Box<dyn Iterator<Item = Commit>>;
fn contains(&self, &CommitId) -> bool;
}
```
But we weren't sure what use case for `iter` would be, so we dropped the `iter`
method. `CachedRevset` with single `contains` method needed a better name. We
weren't able to come up with one, so we decided instead to have a method on
`Revset` that returns a closure to check if a commit is in a revset.
"for<'index> RevWalk<CompositeIndex<'index>, .." works as of now, but it won't
be composed well. So I'll turn CompositeIndex<'_> into &CompositeIndex in the
next batch, and remove "for<'index>".
Just for consistency. Descendants are always evaluated eagerly, so this change
isn't strictly needed.
This eliminates lifetimed fields from RevWalk objects, and the RevWalk object
will be embedded directly in RevWalkRevset.
This patch adds two separate iterator adapters. They are identical at this
point, but I'm going to add detach/reattach methods only to the borrowed
version. I'm also planning to change CompositeIndex<'_> to &CompositeIndex
to get around higher-ranked trait bound restrictions.
This simplifies the RevWalkIndex API. It would probably add fractional msecs of
overhead per next() call, but I don't see significant difference in revset
benches.
The `amend/unamend` aliases exist for smoothen onboarding for
Git/Mercurial users; I don't think we should recommend that users use
them, so I think it's fine if users override them as they
like. Therefore, I think they belong in the config.
Since the return type is no longer "impl Iterator<..>", there isn't lifetime
issue anymore.
I'm going to make CompositeIndex<'_> detachable from the RevWalk, and
"F: Fn(CompositeIndex) -> Box<dyn Iterator<..>>" of RevWalkRevset<F> will
be replaced with "W: RevWalk<CompositeIndex>". This will simplify the code
structure, but also means that we can no longer apply .take_while() here and
convert it back to RevWalk. Fortunately, ancestors_until_roots() is the only
function I need to reimplement.
It doesn't make sense to build BinaryHeap with intermediate type, and I'm
going to reimplement take_until_roots() in a way that the queue drops
uninteresting items.
The current RevWalk constructors insert intermediate items to BinaryHeap
and convert them as needed. This is redundant, and I'm going to add another
parameter that should be applied to the queue first. That's why I decided
to factor out a builder type. I considered adding a few set of factory
functions that receive all parameters, but they looked messy because most of
the parameters are of [IndexPosition] type.
This patch also adds must_use to the builder and its return types, which are
all iterator-like.
I'm planning to add RevWalk trait, and this patch frees up the name. It seems
also good for consistency as we have RevWalkDescendants*.
Although watchman client appears to fail at decoding non-UTF-8 path (somewhere
in serde), jj shouldn't panic if watchman could deal with that.
The outer error message "path not in the repo" would sounds odd, but I think
that's okay because 1. it's unlikely that a user input is not UTF-8, and 2.
it's technically correct that a non-UTF-8 path is not contained in the repo.
This should address both use cases:
1. If from_relative_path() is directly called, the error says ".." shouldn't
be included in the (normalized) relative path.
2. If parse_fs_path() is used, the error message contains paths relative to
cwd. #3216
It generates numerous warnings that it will stop working once Node 16 is
unsupported. This replaces it by a seemingly equivalent action that
somebody is supporting. I tired this change on
https://github.com/ilyagr/diffedit3/, and it seems to work.
I think it would be better to switch to using
https://github.com/shogo82148/actions-upload-release-asset, which is
recommended at https://github.com/actions/upload-release-asset, but that
would be a slight change to the release process (that action creates a
release when a tag is pushed, we'd probably want it to be for tags
starting with `v`), so I'll let @martinvonz do that.
Ultimately, Martin, since you do the releases, it's entirely up to you
what we do here. For example, you can wait until the next release and
experiment with this PR then.
For API consistency. It wouldn't practically matter unless we want to reuse
.iter_graph() in lazy event-driven GUI context.
I don't see significant performance difference:
- jj-0: original impl with look-ahead IndexEntry<'_> buffer
- jj-1: this patch
With dense graph
```
% hyperfine --sort command --warmup 3 --runs 10 -L bin jj-0,jj-1 \
"target/release-with-debug/{bin} -R ~/mirrors/git --ignore-working-copy log -r.. -T ''"
Benchmark 1: target/release-with-debug/jj-0 -R ~/mirrors/git --ignore-working-copy log -r.. -T ''
Time (mean ± σ): 1.367 s ± 0.008 s [User: 1.261 s, System: 0.105 s]
Range (min … max): 1.357 s … 1.380 s 10 runs
Benchmark 2: target/release-with-debug/jj-1 -R ~/mirrors/git --ignore-working-copy log -r.. -T ''
Time (mean ± σ): 1.344 s ± 0.017 s [User: 1.245 s, System: 0.099 s]
Range (min … max): 1.313 s … 1.369 s 10 runs
Relative speed comparison
1.02 ± 0.01 target/release-with-debug/jj-0 -R ~/mirrors/git --ignore-working-copy log -r.. -T ''
1.00 target/release-with-debug/jj-1 -R ~/mirrors/git --ignore-working-copy log -r.. -T ''
```
With sparse graph
```
% hyperfine --sort command --warmup 3 --runs 10 -L bin jj-0,jj-1 \
"target/release-with-debug/{bin} -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''"
Benchmark 1: target/release-with-debug/jj-0 -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''
Time (mean ± σ): 1.347 s ± 0.017 s [User: 1.216 s, System: 0.130 s]
Range (min … max): 1.321 s … 1.379 s 10 runs
Benchmark 2: target/release-with-debug/jj-1 -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''
Time (mean ± σ): 1.379 s ± 0.023 s [User: 1.238 s, System: 0.140 s]
Range (min … max): 1.328 s … 1.403 s 10 runs
Relative speed comparison
1.00 target/release-with-debug/jj-0 -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''
1.02 ± 0.02 target/release-with-debug/jj-1 -R ~/mirrors/git --ignore-working-copy log -r'tags()' -T ''
```
Prepares for removing &CompositeIndex from the RevsetGraphIterator struct.
The input iterator will also be changed to position-based.
I've turned self.look_ahead.get().unwrap() into assertion, but it's not super
important here. It's just for sanity that we've mapped missing edges properly.
FWIW, we could say RevsetGraphIterator is an example of iterating *and* testing
membership of the input revset (though the yielded entries are discarded.)
Bumps the github-dependencies group with 2 updates: [DeterminateSystems/nix-installer-action](https://github.com/determinatesystems/nix-installer-action) and [DeterminateSystems/magic-nix-cache-action](https://github.com/determinatesystems/magic-nix-cache-action).
Updates `DeterminateSystems/nix-installer-action` from 9 to 10
- [Release notes](https://github.com/determinatesystems/nix-installer-action/releases)
- [Commits](https://github.com/determinatesystems/nix-installer-action/compare/cd46bde16ab981b0a7b2dce0574509104543276e...de22e16c4711fca50c816cc9081563429d1cf563)
Updates `DeterminateSystems/magic-nix-cache-action` from 3 to 4
- [Release notes](https://github.com/determinatesystems/magic-nix-cache-action/releases)
- [Commits](https://github.com/determinatesystems/magic-nix-cache-action/compare/eeabdb06718ac63a7021c6132129679a8e22d0c7...fc6aaceb40b9845a02b91e059ec147e78d1b4e41)
---
updated-dependencies:
- dependency-name: DeterminateSystems/nix-installer-action
dependency-type: direct:production
update-type: version-update:semver-major
dependency-group: github-dependencies
- dependency-name: DeterminateSystems/magic-nix-cache-action
dependency-type: direct:production
update-type: version-update:semver-major
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
For the same reason as the previous commit. Since self.inner.positions()
basically clones the underlying evaluation tree, there is no reason to stick
to &self lifetime. Perhaps, some of the CLI utility can be changed to not
collect() the iterator.
Migrating iter_graph() requires non-trivial changes, so it will be done
separately.
Bumps the github-dependencies group with 1 update: [actions/checkout](https://github.com/actions/checkout).
Updates `actions/checkout` from 4.1.1 to 4.1.2
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/b4ffde65f46336ab88eb53be808477a3936bae11...9bb56186c3b09b4f86b1c65136769dd318469633)
---
updated-dependencies:
- dependency-name: actions/checkout
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Bumps the cargo-dependencies group with 3 updates: [anyhow](https://github.com/dtolnay/anyhow), [proc-macro2](https://github.com/dtolnay/proc-macro2) and [thiserror](https://github.com/dtolnay/thiserror).
Updates `anyhow` from 1.0.80 to 1.0.81
- [Release notes](https://github.com/dtolnay/anyhow/releases)
- [Commits](https://github.com/dtolnay/anyhow/compare/1.0.80...1.0.81)
Updates `proc-macro2` from 1.0.78 to 1.0.79
- [Release notes](https://github.com/dtolnay/proc-macro2/releases)
- [Commits](https://github.com/dtolnay/proc-macro2/compare/1.0.78...1.0.79)
Updates `thiserror` from 1.0.57 to 1.0.58
- [Release notes](https://github.com/dtolnay/thiserror/releases)
- [Commits](https://github.com/dtolnay/thiserror/compare/1.0.57...1.0.58)
---
updated-dependencies:
- dependency-name: anyhow
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: proc-macro2
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: thiserror
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
This is the step towards removing &CompositeIndex references from the revset
evaluation tree. The filter input is changed from &IndexEntry to IndexPosition
to simplify the lifetime thingy. We might want to pass around CommitId or
Commit object once it's loaded, but that can be implemented later. I don't
see significant performance difference in revset benches.
This was proposed by @Brixy in
https://github.com/martinvonz/jj/discussions/2882 a while ago. There
seems to be pretty strong consensus that it's a good idea.
I've copied the added test cases from `test_move_command.rs`, just
replacing `move` by `squash`, `--to` by `--into`, and deleting the
test of a no-arg invocation (`jj move` fails, `jj squash` does not -
it defaults to squashing into the parent).
Bumps the cargo-dependencies group with 2 updates: [minus](https://github.com/arijit79/minus) and [whoami](https://github.com/ardaku/whoami).
Updates `minus` from 5.5.3 to 5.6.0
- [Changelog](https://github.com/arijit79/minus/blob/main/CHANGELOG.md)
- [Commits](https://github.com/arijit79/minus/compare/v5.5.3...v5.6.0)
Updates `whoami` from 1.5.0 to 1.5.1
- [Changelog](https://github.com/ardaku/whoami/blob/v1/CHANGELOG.md)
- [Commits](https://github.com/ardaku/whoami/compare/v1.5.0...v1.5.1)
---
updated-dependencies:
- dependency-name: minus
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: cargo-dependencies
- dependency-name: whoami
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
This patch makes `jj squash` us the helper I just extracted from `jj
move`. I had a to add a few small features to it for that.
The `test_squash_command.rs` test changed in a few cases where we do a
partial squash. After this patch, we include the rebased child in the
count of rebased descendants. That seems reasonable and consistent
with partial squash/move further than 1 generation.
We haven't used custom Git commit headers for two main reasons:
1. I don't want commits created by jj to be different from any other
commits. I don't want Git projects to get annoyed by such commit
and reject them.
2. I've been concerned that tools don't know how to handle such
headers, perhaps even resulting in crashes.
The first argument doesn't apply to commits with conflicts because
such commits would never be accepted by a project whether or not they
use custom commit headers. The second argument is less relevant for
conflicted commits because most tools will be confused by such commits
anyway.
Storing conflict information in commit headers means that we can
transfer them via the regular Git wire protocol. We already include
the tree objects nested inside the root-level tree, so they will also
be transferred.
So, let's start by writing the information redundantly to the commit
header and to the existing storage. That way we can roll it back if we
realize there's a problem with using commit headers.
Initially we were thinking to have `Revset` return something like
`CachedRevset`:
```
pub trait CachedRevset {
fn iter(&self) -> Box<dyn Iterator<Item = Commit>>;
fn contains(&self, &CommitId) -> bool;
}
```
But we weren't sure what use case for `iter` would be, so we dropped the `iter`
method. `CachedRevset` with single `contains` method needed a better name. We
weren't able to come up with one, so we decided instead to have a method on
`Revset` that returns a closure to check if a commit is in a revset.
This eliminates lifetimed fields from RevWalk objects, and the RevWalk object
will be embedded directly in RevWalkRevset.
This patch adds two separate iterator adapters. They are identical at this
point, but I'm going to add detach/reattach methods only to the borrowed
version. I'm also planning to change CompositeIndex<'_> to &CompositeIndex
to get around higher-ranked trait bound restrictions.
I'm going to make CompositeIndex<'_> detachable from the RevWalk, and
"F: Fn(CompositeIndex) -> Box<dyn Iterator<..>>" of RevWalkRevset<F> will
be replaced with "W: RevWalk<CompositeIndex>". This will simplify the code
structure, but also means that we can no longer apply .take_while() here and
convert it back to RevWalk. Fortunately, ancestors_until_roots() is the only
function I need to reimplement.
The current RevWalk constructors insert intermediate items to BinaryHeap
and convert them as needed. This is redundant, and I'm going to add another
parameter that should be applied to the queue first. That's why I decided
to factor out a builder type. I considered adding a few set of factory
functions that receive all parameters, but they looked messy because most of
the parameters are of [IndexPosition] type.
This patch also adds must_use to the builder and its return types, which are
all iterator-like.
Although watchman client appears to fail at decoding non-UTF-8 path (somewhere
in serde), jj shouldn't panic if watchman could deal with that.
The outer error message "path not in the repo" would sounds odd, but I think
that's okay because 1. it's unlikely that a user input is not UTF-8, and 2.
it's technically correct that a non-UTF-8 path is not contained in the repo.