We are a little weird about which string escapes we support, and we don't
support raw strings. I thought this might be worth documenting.
Inspired by https://github.com/martinvonz/jj/pull/2251
As suggested by @yuja in
https://github.com/martinvonz/jj/issues/1841#issuecomment-1720451152
Thanks to @lazywei for pointing out that `git pack-refs --all` is better, at
least on the first run. I haven't checked, but suspect, that because of the
number of `refs/jj` refs jj creates, it might always be better.
Perhaps this will stop Github from showing jj-docs-bot as a very active
contributor in https://github.com/martinvonz/jj/pulse. This would
probably fair, even though jj-docs-bot tries its best to be a good and
helpful bot.
Regardless, this seems to be the standard on Github which has
`dependabot[bot]` and `github-actions[bot]`.
This is essentially a new version, which clarifies multiple statements about
`jj run`. Notably, it cleans up some mistakes which were overlooked or deemed
good enough in the Google Docs version.
This ticks another box in #1869.
Co-Authored-By: arxanas <me@waleedkhan.name>
Co-Authored-By: hooper <hooper@google.com>
Co-Authored-By: martinvonz <martinvonz@google.com>
https://github.com/martinvonz/jj/discussions/2230 indicates a lot of
interest in this, so we'd probably want to support this officially at
some point. Until then, document a script that has worked well-enough
for some of us.
I've noticed `WorkspaceCommandHelper::format_file_path()` appear in
profiles a few times. A big part of that is spent in
`RepoPath::to_fs_path()`. I think I had been thinking that
`PathBuf::join()` takes `self` by value and mutates it, but it turns
out it creates a new instance. So our `result = result.join(...)` in a
loop was copying the `PathBuf` over and over. This fixes that and also
reserves the expected size. That speeds up `jj files
--ignore-working-copy -r v6.0` in the Linux repo from 546.0 s to 509.3
s (6.7%).
Summary: By default, and to be explicit, the local flake turns off default
features. But, 70f6e0a turned off watchman support for the Nix build by
accident. Enable default features so this doesn't happen again.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: Ib7dd935eceab328fa5b0333b10368377
I think the feature is requested by enough users that we should
include it by default, also for people who install from source (we
include it in the `packaging` feature already).
It increases the size of the binary from 16.5 MiB to 17.8 MiB. I
suspect we'd see some of that increase in size soon anyway, as I'm
probably going to use Tokio for making async backend requests.
The main goal of this change is to enable tree-level conflict format, but it
also allows us to bulk-import commits on clone/init. I think a separate method
will help if we want to provide progress information, enable check for
.jjconflict entries under certain condition, etc.
Since git::import_refs() now depends on GitBackend type, it might be better to
remove git_repo from the function arguments.
There should be no reason to include `criterion` without the `bench`
feature. Adding the `dep:` prefix to any dependency makes cargo not
expose the implicit `criterion` feature.
Since we have overloaded operator symbols, we need to deduplicate them
upfront. Legacy and compat operators are also removed from the suggestion.
It's a bit ugly to mutate the error struct before calling Error::renamed_rule(),
but I think it's still better than reimplementing message formatting function.
As we discussed in #1928, it seems better to print information about
abandoned commits in the context of the pre-abandon state. For
example, that means that we'll include any branches that pointed to
the now-abandoned commits.
Since e7e49527ef "git: ensure that remote branches never diverge", the last
known "refs/remotes" ref should be synced with the corresponding remote branch.
So we can always trust the branch@remote expression. We don't need "refs/tags"
lookup either since tags should have been imported by git::import_refs().
FWIW, I'm thinking of reorganizing view.git_refs() map as per-remote views.
It would be nice if we can get rid of revsets and template keywords exposing
low-level Git ref primitives.
