E.g. when the user doesn't have the default command set, you don't want
to get
```
Warning: Cannot define an alias that overrides the built-in command 'log'
```
printed on every completion.
This helps sideband writer overwrite the progress bar. Suppose progress
information is less important than sideband messages, it should be okay to
always overwrite the progress bar. The sideband writer will erase the trailing
characters and move the cursor back to the first column, and/or put "\n"
accordingly.
The current comment uses `[noeol]`, which can be difficult to
understand. In this commit, the brackets are changed to parentheses to
make it clear that there is no semantic meaning to the comment, and the
wording is changed to be more clear to the user.
Git doesn't show this information in their "diff3" style either, and it
looks a bit strange having two different bracketed sections of text next
to each other, so I think it would be better to remove it.
When we have e.g. a bookmark name or a remote name and we want to
produce a revset from it, we may need to quote and escape it. This
patch implements a function for that.
Perhaps we'll want to more generally be able to format a whole
`RevsetExpression` later.
With this and "git --progress" PR #5519, remote git progress will be displayed.
The sideband callback is disabled in git2 code path if progress is not enabled.
If this were enabled, most "git fetch" tests would fail with git2 due to remote
progress messages. Since there's no git2 API to turn the remote progress off,
and the git2 code path is supposed to be phased out, I just inserted ad-hoc
workaround.
This patch adds thread-based implementation. On Unix, we can poll pipes without
using thread, but I don't think platform-dependent optimization is needed.
The meaning of `[noeol]` might not be immediately clear to a user, so it
would be good to document it on our documentation page for conflicts. We
may also want to improve the conflict marker comments we use for this
case in the future (possibly after receiving user feedback).
This will be more robust long term since e.g. native ARM runners use
`ubuntu-24.04-arm` as their runner image, and the version number really
isn't a big deal in this case.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Overall, building in the test profile should significantly speed up
the overall build pipeline because so many less cycles are spent (on
GHA runners that are certainly at high load). The goal here is to help
reduce CI flake outs due to things timing out; I suspect part of the
problem may be a lot of the ~15 minute time limit being used up just
compiling things.
This is a partial revert of b714592952400ab, which removed this previous
override of the Flake `checks`.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Some of our builds have been timing out, and one angle I want to look at
is whether any tests are hanging. Nextest can help us keep track of slow
tests in CI where the underlying hosts will have significantly higher
load. In general this should also help keep our tests healthy, IMO.
I don't see any reason why any existing test should take over 20
seconds, but it should at least help control for really slow runners
that have huge latency spikes. we can start there and see how it goes
in practice.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
* Make the new `GitFetch` api public.
* Move `git::fetch` to `lib/tests/test_git.rs` as `git_fetch`, to minimize
churn in the tests. Update test call sites to use `git_fetch`
* Delete the `git::fetch` from `lib/src/git.rs`.
* Update `jj git clone` and `git_fetch` in `cli/src/git_utils.rs` to use
the new api directly. Removing one redundant layer of indirection.
* This fixes#4920 as it first fetches from all remotes before `import_refs()`
is called, so there is no race condition if the same commit is treated
differently in different remotes specified in the same command.
Original commit by @essiene
The primary goal is to control the version of the `codespell` Python
package that we run via `uv.lock`. See also
https://github.com/jj-vcs/jj/pull/5425.
Also move the action next to the `cargo fmt` action. It might make sense
to split both of them out of `build.yml` if it gets too long, but I
think they should be next to each other since they are so similar in
spirit.
Fixes#5490 (we can catch other instances of this manually)
Note that it links to the `latest` even if you are looking at the
`prerelease` docs. This is not ideal, but seems annoying to fix.
