commits
Replace `jj 0.10.0-20231027-bb8af5adc4f98ff2` with `jj 0.10.0+20231027-bb8af5adc4f98ff2`.
According to https://semver.org, the build metadata should be separated by a
`+`, not `-`. If semver rules are pedantically followed, `jj
0.10.0-20231027-bb8af5adc4f98ff2` sorts before `jj 0.10.0`, whereas the build
metadata is ignored for the purposes of ordering.
I'm not sure whether anybody else is likely to treat the full `jj version`
string as a semver this pendantically, but we can :).
I discovered this when thinking about #2258; see that PR for a few more details
about pedantic semvers.
Thanks to @thoughtpolice for providing the original version of the nix code; I
edited it a bit.
16 characters ought to be enough for anyone :)
The date comes from the commiter date of the commit. This is so that
it's easy to tell at a glance how old a version is.
To make it easier to get UTC date, we first obtain it as a Unix
timestamp, which should always be UTC. This will make the
interaction with Nix in a subsequent commit easier.
Someone at work asked me why I started jj when Sapling already
existed. Let's clarify that I started it before.
The command only takes a snapshot and avoids other overhead, so it can
be used as a target for the watchman trigger that gets installed.
Moved commands are `git clone`, `git export`, `git fetch`, `git import`,
`git init`, `git push`, `git remote`, and `git submodule`.
This makes the examples in
https://martinvonz.github.io/jj/prerelease/revsets/#operators render
properly at the cost of worse (but readable) rendering on GitHub.
Also fixes a typo.
This basically supersedes the current "branch set" command. The plan is to turn
"branch set" into an "upsert" command, and deprecate "branch create". (#3584)
Maybe we can also add "branch set --new" flag to only allow creation of new
branches. One reason behind this proposed change is that "set" usually allows
both "creation" and "update". However, we also need a typo-safe version of
"set" to not create new branches by accident.
"jj branch move" is useful when advancing ancestor branches. Let's say you've
added a couple of commits on top of an existing PR branch, you can advance the
branch by "jj branch move --from 'heads(::@- & branches())' --to @-". If this
pattern is super common, maybe we can add --advance flag for short.
One drawback of this change is that "git branch --move" is equivalent to
"jj branch rename". I personally don't find this is confusing, but it's true
that "move" sometimes means "rename".
This basically backs out 8706fadca182 "cli: inline check for
non-fast-forwardable branch move." I'm going to add another subcommand that
moves existing branches.
By running CI on push to any branch, collaborators can check that CI
passes before sending for review, reducing mail spam and wasted
reviewer time before the code is ready.
Otherwise they wouldn't be sorted in help. I also reordered the match statement.
Since subcommands are split to per-file modules, there's no point to keep some
logical ordering.
These two aliases didn't survive code review.
Bumps [urllib3](https://github.com/urllib3/urllib3) from 2.2.1 to 2.2.2.
- [Release notes](https://github.com/urllib3/urllib3/releases)
- [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst)
- [Commits](https://github.com/urllib3/urllib3/compare/2.2.1...2.2.2)
---
updated-dependencies:
- dependency-name: urllib3
dependency-type: indirect
...
Signed-off-by: dependabot[bot] <support@github.com>
It's cumbersome to unwrap the Option just to print a short hint message. Let's
send the message to null output instead.
ui.hint_*() calls will be inlined by the next commit.
This makes it clear that these hints are printed only if status output is
enabled.
I'm going to add a few callers of .with_heading() outside of ui.rs.
Thank you all for building tools around it.
- rearrange the files involved to be more clear about structure
- deprecate existing `jj cat` and `jj chmod`
The ReadFile error message already says "when reading file content for file
{path}..".
The function has no callers outside the module anymore (probably since
`MaterializeTreeValue` but I haven't checked). Inlining it will help
keep error handling simple in the next commit. Otherwise we'd need to
have it return an error type wrapping both `BackendError` and
`io::Error`.
I don't think the message adds anything over what the `BackendError`
itself provides, so let's use `transparent` instead.
I also dropped the `Internal` prefix from the variant because that
also didn't seem to add anything.
- make an internal set of watchman extensions until the client api gets
updates with triggers
- add a config option to enable using triggers in watchman
Co-authored-by: Waleed Khan <me@waleedkhan.name>
There's been a lot of questions about the subtle differences between
`..` and `::`. I hope these examples will help with that.
We should also add examples to the revset functions (e.g. `heads()` is
not obvious how it works), but that can come later.
`..` is shorthand for `root()..visible_head()`, for example. We don't
seem to explain that anywhere. I hope mentioning that will help
readers understand the relationship between the shorthands and the
full `x..y`, and also to see the correspondence between `..` and `::`
(in how their default left and right operands are the same).
If I can't tell what this comment means, probably nobody else can
either.
I think it might be a copy-paste error from whatever docs I copied the
initial version of the config from.
That old commit made a piece of documentation obsolete, but
I didn't realize it at the time.
I am currently not aware of any severe differences between the generated
markdown and `jj help`, though this could change if we look over the
text carefully or if we start using `clap` features we weren't using
before.
Fixes important bugs. 🎉
Without this, `cargo deny` fails after a `cargo update`
(https://github.com/martinvonz/jj/actions/runs/9531433728/job/26272377250?pr=3892
failed, but once it includes this commit, #3892 no longer has a `cargo
deny` failure. The windows failure is unrelated))
This better matches `jj parallelize`.
This better matches `git log` and affects `jj log`, `jj op log` and `jj obslog`
Still alias function shadows builtin function (of any arity) by name. This
allows to detect argument error as such, but might be a bit inconvenient if
user wants to overload heads() for example. If needed, maybe we can add some
config/revset syntax to import builtin function to alias namespace.
The functions table is keyed by name, not by (name, arity) pair. That's mainly
because std collections require keys to be Borrow, and a pair of borrowed
values is incompatible with owned pair. Another reason is it makes easy to look
up overloads by name.
Alias overloading could also be achieved by adding default parameters, but that
will complicate the implementation a bit more, and can't prevent shadowing of
0-ary immutable_heads().
Closes #2966
I'm going to add arity-based alias overloading, and we'll need function
(name, arity) pair to identify it in alias expansion stack. The exact parameter
names aren't necessary, but they can be embedded in error messages.
Most of the value of `jj fix` over a shell script is in formatting commits
other than `@`. `@::` often doesn't contain those other commits, so `-s @` is a
bad default.
We could get the same effect from `-s 'mutable() & ::@'`, but `reachable()` is
a bit more explicit and simple to read.
We could also base this on excluding `trunk()`, but that just seems like an
indirection for `mutable()` that might ignore the user's intent if they have
configured part of trunk to be mutable.
This cuts the size of a final debug binary in half (~250MiB -> 127MiB)
in my dev shell, and saves about 15% of total `target/` directory size
when a full build from scratch happens (2GiB -> 1.7GiB). Let's take an
easy free win.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Only active within `devShell`; the default `.#jujutsu` package is unaffected
by this change. This somewhat increases CPU utilization and has a marginal
improvement on my local compile times, but it's also nice if you have to
recompile from scratch too.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I07ab28991843ca3723185569db5f38f2ed076875
This is a change that does affect the nix built package, and is tested as part
of the CI Matrix, so there is now an actively maintained (by me) nightly build
that can be checked for regressions.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: If9a134de7e1d496d47936259c59f73c4a62a341f
Replace `jj 0.10.0-20231027-bb8af5adc4f98ff2` with `jj 0.10.0+20231027-bb8af5adc4f98ff2`.
According to https://semver.org, the build metadata should be separated by a
`+`, not `-`. If semver rules are pedantically followed, `jj
0.10.0-20231027-bb8af5adc4f98ff2` sorts before `jj 0.10.0`, whereas the build
metadata is ignored for the purposes of ordering.
I'm not sure whether anybody else is likely to treat the full `jj version`
string as a semver this pendantically, but we can :).
I discovered this when thinking about #2258; see that PR for a few more details
about pedantic semvers.
This basically supersedes the current "branch set" command. The plan is to turn
"branch set" into an "upsert" command, and deprecate "branch create". (#3584)
Maybe we can also add "branch set --new" flag to only allow creation of new
branches. One reason behind this proposed change is that "set" usually allows
both "creation" and "update". However, we also need a typo-safe version of
"set" to not create new branches by accident.
"jj branch move" is useful when advancing ancestor branches. Let's say you've
added a couple of commits on top of an existing PR branch, you can advance the
branch by "jj branch move --from 'heads(::@- & branches())' --to @-". If this
pattern is super common, maybe we can add --advance flag for short.
One drawback of this change is that "git branch --move" is equivalent to
"jj branch rename". I personally don't find this is confusing, but it's true
that "move" sometimes means "rename".
Bumps [urllib3](https://github.com/urllib3/urllib3) from 2.2.1 to 2.2.2.
- [Release notes](https://github.com/urllib3/urllib3/releases)
- [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst)
- [Commits](https://github.com/urllib3/urllib3/compare/2.2.1...2.2.2)
---
updated-dependencies:
- dependency-name: urllib3
dependency-type: indirect
...
Signed-off-by: dependabot[bot] <support@github.com>
`..` is shorthand for `root()..visible_head()`, for example. We don't
seem to explain that anywhere. I hope mentioning that will help
readers understand the relationship between the shorthands and the
full `x..y`, and also to see the correspondence between `..` and `::`
(in how their default left and right operands are the same).
Still alias function shadows builtin function (of any arity) by name. This
allows to detect argument error as such, but might be a bit inconvenient if
user wants to overload heads() for example. If needed, maybe we can add some
config/revset syntax to import builtin function to alias namespace.
The functions table is keyed by name, not by (name, arity) pair. That's mainly
because std collections require keys to be Borrow, and a pair of borrowed
values is incompatible with owned pair. Another reason is it makes easy to look
up overloads by name.
Alias overloading could also be achieved by adding default parameters, but that
will complicate the implementation a bit more, and can't prevent shadowing of
0-ary immutable_heads().
Closes #2966
Most of the value of `jj fix` over a shell script is in formatting commits
other than `@`. `@::` often doesn't contain those other commits, so `-s @` is a
bad default.
We could get the same effect from `-s 'mutable() & ::@'`, but `reachable()` is
a bit more explicit and simple to read.
We could also base this on excluding `trunk()`, but that just seems like an
indirection for `mutable()` that might ignore the user's intent if they have
configured part of trunk to be mutable.
Only active within `devShell`; the default `.#jujutsu` package is unaffected
by this change. This somewhat increases CPU utilization and has a marginal
improvement on my local compile times, but it's also nice if you have to
recompile from scratch too.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I07ab28991843ca3723185569db5f38f2ed076875