The count() function in this trait is used by "jj branch" to determine
(and then report) how many commits a certain branch is ahead/behind
another branch. This is currently implemented by walking all commits
in the revset, counting how many were encountered. But this could be
improved: if the number is large, it is probably sufficient to report
"at least N" (instead of walking all the way), and this does not scale
well to jj backends that may not have all commits present locally (which
may prefer to return an estimate, rather than access the network).
Therefore, add a function that is explicitly documented to be O(1)
and that can return a range of values if the backend so chooses.
Also remove count(), as it is not immediately obvious that it is an
expensive call, and callers that are willing to pay the cost can obtain
the exact same functionality through iter().count() anyway. (In this
commit, all users of count() are migrated to iter().count() to preserve
all existing functionality; they will be migrated to count_estimate() in
a subsequent commit.)
"branch" needed to be updated due to this change. Although jj
is currently only available in English, I have attempted to keep
user-visible text from being assembled piece by piece, so that if we
later decide to translate jj into other languages, things will be easier
for translators.
A subsequent commit will teach more variants of ahead/behind messages,
so refactor the existing code to avoid code duplication and a future
combinatorial explosion.
Summary: Pure QOL improvement, not that this was too awful as it stood. But this
ultimately makes all builds faster, effectively for free; on my Linux machine,
debug link time for jj-cli goes from 3s to 1s.
This was originally submitted as part of #1864, and backed out as part of #1982,
because the default `mold` package did not have the proper "wrapper script"
that allowed it to find the right external libraries. Using the `mold-wrapped`
package however fixes this.
On top of that, let's go ahead and make `mold` the default linker in the Nix
package/flake as well; this should improve the `nix build` speed since a lot of
tests need to be linked.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
On my machine, this halves the time taken by `cargo insta test --workspace
--test-runner nextest`.
I don't believe there would be a worthwhile improvement when not
using `nextest`. I also documented how to tell whether using `mold`
is worthwhile.
I was reminded of this by https://github.com/martinvonz/jj/pull/2858.
Gerrit also needs to be able to push low-level refs into upstream remotes, just
like `jj git push` does. Doing so requires providing callbacks e.g. for various
password entry mechanisms, which was private to the `git` command module.
Pull these out to a new module `git_utils` so we can reuse it across the two
call sites.
This also moves a few other strictly Git-related functions into `git_utils`
as well, just for the sake of consistency.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
A version of smallvec was yanked from crates.io, causing
failures like the one in #2848. This should fix that.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I02f8ec4d0dcdc7014caae89def27cf250dc846bd
Summary: Includes a newer version of `cargo nextest`, which has
some nice little features (like the `binary_id()` filter.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: Ie6f822d3a5c16ec30e41bc830ee4b580a6547428
Summary: It needs new credentials to act as a robot account on my behalf, rather
than the 'github-actions' user, as that one can't be approved for security/legal
reasons from Google.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I72e303b5625a6417d3444fc65cb79a779a5d9d53
GitBackend::gc() will recreate no-gc refs for the indexed heads. We could
collect all historical heads by traversing operation log, but it isn't enough
because there may be predecessor links to hidden commits, and "git gc" isn't
aware of predecessors.
This also means that we can implement GC without taking care of extra
metadata. I haven't tried, but it wouldn't be easy to keep Git refs and extra
table in sync.
The idea is that GC, if implemented, will clean up objects based on the Index
knowledge. It's probably okay to leave some extra metadata of unreachable
objects, but GC-ed refs should be recreated if the corresponding heads get
reimported. See also the next patch.
This will allow us to issue multiple prevent_gc() requests all at once. It's
not important here, but will be unavoidable when implementing GC. Deleting
tons of refs from packed refs is super slow if the requests were processed one
by one.
* Move canonicalization of the external git repo path into the Workspace::init_git_external().
This keeps necessary code together.
* Add a new variant of WorkspaceInitError for reporting path not found errors. The user error
string is written to pass existing tests.
Because the default index cuts off the traversal at min(generations), including
the root id means all ancestors will be visited. This could be worked around at
the index side, but I think it's the repo/view's responsibility. That being
said, it's not uncommon to pad a revset with "root()", so it might make sense
for the index to special case the root id.
I also removed the redundant .clone().
It seems obvious in hindsight to have a virtual root operation just
like we have a virtual root commit. It removes the same kind of
problems by making sure there's always a common ancestor (or multiple)
between any two commits.
I think the reason I didn't add a root operation from the beginning
was that there used to be a mandatory working-copy commit in the view
(this was before support for multiple workspaces).
Perhaps we should remove the "initialize repo" operation now. The only
difference between their view objects is that the "initialize repo"
operation adds the root commit as a head. We could add that to the
root operation, but then the root operation's value depends on the
commit backend.
We've had the public_heads for as long as we've had the View object,
IIRC (I didn't check), but we still don't use it for anything. I don't
have any concrete plans for using it either. Maybe our config for
immutable commits is good enough, or maybe we'll want something more
generic (like Mercurial's phases). For now, I think we should simplify
by removing it the storage for public heads.
This function respects --ignore-working-copy and --at-op arguments, but the
name snapshot() sounds like it could forcibly trigger the snapshotting. Let's
clarify the actual behavior.
import_git_refs_and_head() and snapshot_working_copy() are unchecked functions,
and there are no external callers.
