On Thu, 3 Apr 2025 at 09:39, Elijah Newren <newren@xxxxxxxxx> wrote:
>
> On Thu, Apr 3, 2025 at 9:25 AM Remo Senekowitsch <remo@xxxxxxxxxxx> wrote:
> >
> > On Thu Apr 3, 2025 at 5:56 PM CEST, Elijah Newren wrote:
> > > On Thu, Apr 3, 2025 at 2:13 AM Patrick Steinhardt <ps@xxxxxx> wrote:
> > >>
> > >> - Extending revisions to allow specifying commits by change ID.
> > >
> > > Would this essentially be similar to <rev>^{/<text>} except searching
> > > specifically change-id headers rather than commit message?
> >
> > One benefit of using the "reverse-hex" format (hex with a different
> > alphabet: z(0) through k(25)) we're proposing is that it allows a
> > change-id or its prefix to be used in the same place as a commit hash,
> > without ambiguity.
>
> I already saw that, but this doesn't address my question.
Jujutsu has a persistent index of change ids to commit ids. It's
similar to Git's commit graph. As you might expect, this index often
has multiple commits for a single change id. When needed, we then
build an in-memory index of only the subset of commits currently
reachable from the visible head commits (you can think of it as all
currently reachable commits from Git branches, but we don't require a
branch to keep a commit visible). When you do something like `jj show
xyz`, we use that in-memory index to find the relevant commits. That's
usually just one commit.
By the way, we actually have another level of lookup that happens
before that. You can configure an expression for the set of commits
you want to prioritize short change id prefixes and commit id prefixes
for. If you say that you want all commits that are not ancestors of
any remote-tracking branch to be shorter, for example, then we build
an additional in-memory index of only those commits. That means that
both change id prefixes and commit id prefixes are often just a few
characters long, even in huge repos like the monorepo at Google.
