mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <>
Subject: [TOPIC 8/12] Update on jj, including at Google
Date: Mon, 2 Oct 2023 11:21:23 -0400	[thread overview]
Message-ID: <ZRrf8zmU5hucarsx@nand.local> (raw)
In-Reply-To: <ZRregi3JJXFs4Msb@nand.local>

(Presenter: Martin von Zweigbergk, Notetaker: Glen Choo)

* (Martin) jj team at Google has been growing. The support for different commit
  "backends" has been expanding - we can now store "commits in the cloud" using
  the Google-internal backend.
   * "Revset" engine. Revset is a language for selecting commits (e.g. "select
     all commits by me"). We now have an implementation that scales to Google's
     millions of commits. Commit id prefixes are resolved against the "local"
     commits (not the full Google mainline).
   * Conflicts are now stored tree-level, instead of per-file level. Conflict
     detection is much faster since jj doesn't need to traverse the tree.
   * Exporting jj commits to internal code review tool (Critique).
* (Martin) What's left?
   * Renames: do we track renames? Do we detect them?
* (Elijah) If conflicts are tree-level, can you store partially-resolved
   * (Martin) Yes, we store trees for each side of the conflict and resolve the
     conflicts only when needed.
* (Jrnieder) Are there lessons from jj development that Git would benefit from?
  What can Git do to make jj's life easier, and vice-versa?
   * (Martin) Conflicts-in-code work extremely well. I think Git could adopt
     that, but it would be very messy to migrate the UX to that. The operation
     log (a global view of all of the refs at a given "operation") is also a big
     improvement over e.g. the reflog.
   * (Martin) jj uses libgit2 (with Rust bindings) under the hood, so we're
     missing functionality like partial clone.
   * (Taylor) do you shell out to git, or only use libgit2? If you did shell
     out, are there other missing Git functions that you'd want?
      * (Martin) Only libgit2. Can't think of other features jj would want.
      * Until merge-ort existed, worktreeless merge would be an example.
      * (Glen) When jj pushes things to a Git server, it loses information. If
        the server understood obsolescence markers, that would be a huge
        improvement for jj.
      * (Martin) Yes, jj uses a change-id to associate different amended
        versions of the same change, similar to Gerrit - it would be nice for
        Git to support the same thing.
* (Junio) Did you have to make any breaking changes that affect your users?
   * (Martin) We make many. We're a small project, and people accept that it
     needs to break to get a nicer UX, which is a nice thing about being early
     in a project.
   * Format-wise, we try not to break the repo format - in terms of newer
     versions of jj being able to work with older versions of repositories.
     Older versions of jj are not expected to always be able to read repos
     written to by a newer version.
      * (Jonathan) "svn upgrade" style?
      * (Martin) Yes, except we immediately do the upgrade automatically.
      * (Jonathan) So the moment you use the new version of jj, you lose the
        ability to roll back.
      * (Martin) Yes. Errors out (crashes) when reading the format it doesn't
      * One of these was annoying for users, we may be at the point where we
        need something more formal.
   * (Junio) In 2005, we did two huge breaking changes in the repo format. There
     were lots of users, but we did it anyway. One was about object naming (used
     to compress first, then hash, which was a bad way of doing it - swapped the
     order to compress better and faster without changing object names).
* (Elijah) If we rewrote parts of Git in Rust, would we be able to share code?
   * (Martin) Possibly, but it would require a lot of rewriting to make that
* (Emily) Greenfield features in jj, e.g. preventing users from rewriting
  "public" commits/history. Are there other ideas would we like to try in jj
  that are harder to do in Git?
   * concept of makes some things (like
     safe interactive rebase) easier
   * (Terry) The usual practice is to have policies on branches (some branches
     are more experimental, some have stringent quality requirements, etc), but
     those are implemented on the hosting provider, not the VCS.
* (Terry) jj has lots of glowing reviews! Power users are happy with it, using
  jj locally. If anything is not supported in jj, they can use Git instead. Is
  there a roadmap for simplifying the experience for non-power users, having it
  automatically take care of things like when to run gc, etc?
   * (Martin) Re: gc, jj doesn't implement it yet.
   * (Terry) More general UX. If I'm a developer using git repositories and want
     to use jj, when do I get to a place where I have a nice end-to-end
   * (Martin) I already use jj, I don't have the "colocated repo" so I only run
     jj commands, can't run git commands. For blame I fall back to the hosting
     provider's web UI. :) That's something to add.
   * (Jrnieder) My impression from the jj discord is that the UX is very
     dependent on their code review tool. Amending/rebasing and sending to
     GitHub seems to work OK. Losing the obsolescence information when pushing
     to Gerrit works quite poorly.
* (Minh) Does jj store commits in Git form? Can it translate between different
  commit representations?
   * (Martin) It can store commits in Git form. The demand for on-the-fly
     conversion has come up.
* (Taylor) How does jj represent non-Git concepts in Git format, like having
  multiple trees in a commit?
   * (Martin) It stores extra metadata outside of the Git commits, and also it
     stores its own shape in Git format, e.g. for multiple trees, each tree is
     its own directory.
* (Minh) How do you optimize searches like "commits written by me"? Full text
   * (Martin) It's implementation-specific. On local repos, it just iterates
   * (Martin) The revset language is quite expressive, e.g. you can specify AND
     and OR. The language is also separate from implementation.
* (Jakub) There are other tools that implement a query language for Git. It
  could be worth considering implementing one natively. (See Git Rev News

  parent reply	other threads:[~2023-10-02 15:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-02 15:15 Notes from the Git Contributor's Summit, 2023 Taylor Blau
2023-10-02 15:17 ` [TOPIC 0/12] Welcome / Conservancy Update Taylor Blau
2023-10-02 15:17 ` [TOPIC 1/12] Next-gen reference backends Taylor Blau
2023-10-02 15:18 ` [TOPIC 02/12] Libification Goals and Progress Taylor Blau
2023-10-02 15:18 ` [TOPIC 3/12] Designing a Makefile for multiple libraries Taylor Blau
2023-10-02 15:19 ` [TOPIC 4/12] Scaling Git from a forge's perspective Taylor Blau
2023-10-02 15:19 ` [TOPIC 5/12] Replacing Git LFS using multiple promisor remotes Taylor Blau
2023-10-02 15:20 ` [TOPIC 6/12] Clarifying backwards compatibility and when we break it Taylor Blau
2023-10-02 15:21 ` [TOPIC 7/12] Authentication to new hosts without setup Taylor Blau
2023-10-02 15:21 ` Taylor Blau [this message]
2023-10-02 15:21 ` [TOPIC 9/12] Code churn and cleanups Taylor Blau
2023-10-02 15:22 ` [TOPIC 10/12] Project management practices Taylor Blau
2023-10-02 15:22 ` [TOPIC 11/12] Improving new contributor on-boarding Taylor Blau
2023-10-02 15:22 ` [TOPIC 12/12] Overflow discussion Taylor Blau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZRrf8zmU5hucarsx@nand.local \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).