Old P::wrap_<type>() functions will be removed, and the wrap_<type>() callbacks
will be replaced with L::Property: WrapTempalteProperty<C> trait bounds. We
could instead use the std From trait, but my feeling is that we would be better
off using less-generic abstraction. It's unlikely that external callers would
have to use this trait.
This will help define List<T> template methods as table of fn(..)s. I think the
parsing/building API will look slightly nicer.
I'm going to add generic wrap(BoxedTemplateProperty<T>) trait, which means a
conversion from T should be uniquely defined. Even though we won't add the ()
template type, it's better to not reserve () for tests.
This makes it clear that the repo state isn't mutated during computation of the
destination and descendants. Still compute_move_commits() is big, so we might
want to split it further. If needed, maybe we can add variants of
apply_move_commits() to fix up intermediate predecessor chains?
compute_move_commits() needs (immutable) &MutableRepo because it depends on
repo.find_descendants_for_rebase().
It's tedious to update Windows code that isn't compiled locally.
In order to ensure conversion between bool and platform-native type, this patch
changes the type alias to real struct. I think this is also good if we decide to
retain executable bits on all platforms.
The former wording of "With the `-r` option, which is the default" is
confusing, and made redundant by the clarifications within the
option-level documentation.
The former wording of "[w]ith the `-r` option, which is the default..." is
a bit confusing. This change brings `jj diff`'s documentation more in
line with the other commands with similar semantics, such as `jj rebase`.
I was wondering whether this is presentation issue or not, and I think it is a
matter of DiffLineIterator. For matching hunks, DiffLineIterator flushes the
current_line buffer and bumps the line numbers for the next line. This should
guarantee that there are no blank DiffLine to be queued. However, for different
hunks, only the left line number can be bumped in the first loop, so there may
be an empty-looking hunk having the same right line number.
Closes#6471
The command has displayed all parents and the diff summary from the
merged parents since 48c44344bfb3 (2022-12-04) but it still says that
it only cares about the first commit. This patch finally fixes that.
We haven't had any reports of problems from people who opted in. Since
it's early in the release cycle now, let's now test it on everyone who
builds from head, so we get almost a month of testing from those
people before it's enabled by default in a released version.
This impacts lots of test cases because the change-id header is added
to the Git commit. Most are uninteresting. `test_git_fetch` now sees
some divergent changes where it used to see only divergent bookmarks,
which makes sense.
I spent quite a while confused by the presence of
`if(!trailers.contains_key("Change-Id")` in the `commit_trailers` example. My
thinking was: if `commit_trailers` already performs deduplication, then isn't
this logic useless?
Eventually I realized that the `commit_trailers` deduplication works on the
entire line, not just the key as I'd assumed. (And that makes sense for
trailers like Signed-off-by that can appear more than once.)
I've reworded the `commit_trailers` documentation to try to make this more
clear.
to set the message on the first commit, where the selected
changes are going. The commit with the remaining changes
keeps the original description.
With this option it becomes possible to use split in a fully
non-interactive way, in combination with the filset feature.
It also makes jj split more consistent with other commands
like squash, commit or new.
`heads(tags())` was rather confusing in my repository because I have
a bunch of tags pushed to my fork that are tracked locally. Assuming
that `trunk()` is something like `main@origin` or whatnot, then using
`heads(tags() & ::trunk())` works quite a bit better.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
