v0.38.0

[martinvonz]

About

jj is a Git-compatible version control system that is both simple and powerful. See
the installation instructions to get started.

Release highlights

• Per-repo and per-workspace config is now stored outside the repo, for security
  reasons. This is not a breaking change because we automatically migrate
  legacy repos to this new format. .jj/repo/config.toml and
  .jj/workspace-config.toml should no longer be used.

Breaking changes

• The minimum supported git command version is now 2.41.0. macOS users will
  need to either upgrade "Developer Tools" to 26 or install Git from
  e.g. Homebrew.

• Deprecated ui.always-allow-large-revsets setting and all: revset modifier
  have been removed.

• <name>@<remote> revset symbols can also be resolved to remote tags. Tags are
  prioritized ahead of bookmarks.

• Legacy placeholder support used for unset user.name or user.email has been
  removed. Commits containing these values will now be pushed with jj git push
  without producing an error.

• If any side of a conflicted file is missing a terminating newline, then the
  materialized file in the working copy will no longer be terminated by a
  newline.

Deprecations

• The revset function diff_contains() has been renamed to diff_lines().

New features

• jj git fetch now shows details of abandoned commits (change IDs and
  descriptions) by default, matching the jj abandon output format.
  #3081

• jj workspace root now accepts an optional --name argument to show
  the root path of the specified workspace (defaults to the current one). When
  given a workspace that was created before this release, it errors out.

• jj git push --bookmark <name> will now automatically track the bookmark if
  it isn't tracked with any remote already.

• Add git_web_url([remote]) template function that converts a git remote URL
  to a web URL, suitable for opening in a browser. Defaults to the "origin"
  remote.

• New divergent() revset function for divergent changes.

• String pattern values in revsets and templates can now be substituted by
  aliases. For example, grep(x) = description(regex:x) now works.

• A new config option remotes.<name>.auto-track-created-bookmarks behaves
  similarly to auto-track-bookmarks, but it only applies to bookmarks created
  locally. Setting it to "*" is now the closest replacement for the deprecated
  git.push-new-bookmarks option.

• jj tag list can now be filtered by revset.

• Conflict markers will use LF or CRLF as the line ending according to the
  contents of the file.
  #7376

• New experimental jj git fetch --tag flag to fetch tags in the same way as
  bookmarks. If specified, tags won't be fetched implicitly, and only tags
  matching the pattern will be fetched as <name>@<remote> tags. The fetched
  remote tags will be tracked by the local tags of the same name.

• New remote_tags() revset function to query remote tags.

• New builtin hyperlink() template function that gracefully falls back to
  text when outputting to a non-terminal, instead of emitting raw OSC 8 escape
  codes. #7592

Fixed bugs

• jj git init --colocate now refuses to run inside a Git worktree, providing
  a helpful error message with alternatives.
  #8052

• jj git push now ensures that tracked remote bookmarks are updated even if
  there are no mappings in the Git fetch refspecs.
  #5115

• jj git fetch/push now forwards most of git stderr outputs such as
  authentication requests. #5760

• Conflicted bookmarks and tags in trunk() will no longer generate verbose
  warnings. The configured trunk() alias will temporarily be disabled.
  #8501

• Dynamic shell completion for jj config unset now only completes
  configuration options which are set.
  #7774

• Dynamic shell completion no longer attempts to resolve aliases at the
  completion position. This previously prevented a fully-typed alias from
  being accepted on some shells and replaced it entirely with its expansion on
  bash. Now, the completion will only resolve the alias, and suggest candidates
  accordingly, after the cursor has been advanced to the next position.
  #7773

• Setting the editor via ui.editor, $EDITOR, or JJ_EDITOR now respects shell quoting.

• jj gerrit upload will no longer swallow errors and surface if changes fail
  to get pushed to gerrit.
  #8568

• jj file track --include-ignored now works when fsmonitor.backend="watchman".
  #8427

• Conflict labels are now preserved correctly when restoring files from commits
  with different conflict labels.

• The empty tree is now always written when the working copy is empty.
  #8480

• When using the Watchman filesystem monitor, changes to .gitignore now trigger
  a scan of the affected subtree so newly unignored files are discovered.
  #8427

• --quiet now hides progress bars.

Contributors

Thanks to the people who made this release happen!

• Benjamin Davies (@Benjamin-Davies)
• Bryce Berger (@bryceberger)
• Chris Rose (@offbyone)
• Daniel Morsing (@DanielMorsing)
• David Fröhlingsdorf (@2079884FDavid)
• David Higgs (@higgsd)
• David Rieber (@drieber)
• Federico G. Schwindt (@fgsch)
• Gaëtan Lehmann (@glehmann)
• George Christou (@gechr)
• itstrivial
• Jeff Turner (@jefft)
• Jonas Greitemann (@jgreitemann)
• Jonas Helgemo (@jonashelgemo)
• Joseph Lou (@josephlou5)
• Kaiyi Li (@06393993)
• Lukas Wirth (@Veykril)
• Martin von Zweigbergk (@martinvonz)
• Matt Stark (@matts1)
• Paul Smith (@paulsmith)
• Pavan Kumar Sunkara (@pksunkara)
• Philip Metzger (@PhilipMetzger)
• Remo Senekowitsch (@senekor)
• Sami Jawhar (@sjawhar)
• Scott Taylor (@scott2000)
• Simone Cattaneo (@simonecattaneo91)
• Steve Klabnik (@steveklabnik)
• tom (@lecafard)
• Vincent Ging Ho Yim (@cenviity)
• _WD_ (@0WD0)
• xtqqczze (@xtqqczze)
• Yuya Nishihara (@yuja)
• yz (@yzheng453)

---

This discussion was created from the release v0.30.0.

[joyously]

New experimental jj git fetch --tag flag
New remote_tags() revset function

I saw these two features and thought I should try them out on the new release. Then I realized I would have to install it first. 😄 Four minutes of download/compile later, I didn't really see how to use the new revset function, so I did the normal plain jj git fetch. I could see several things different, like moving a config file (which I didn't make). That got me wondering if using rsync on repos is still viable as stated in the Concurrency page, and if a config file can contain anything 1) that needs to be there for the repo to be "complete", or 2) that is private and will be copied to the home directory of someone with access to the legacy version of the repo. In other words, if someone makes backup copies of jj repos on Dropbox (as in the docs), the embedded repo config makes them "whole", but now anyone else using them gets the config copied to their home directory. And will the symbolic link that replaces the config be an error when I restore a new backup on a different machine?

The reason I'm posting here, is about the release tag. My copy of the jj code is only used to have a large repo for jj. I don't change code; I simply compile and barely look around. The last fetch was probably 1 week ago. My confusion is with the new messages from fetch about abandoned commits, where the description is "release: 0.38.0", which I assume would be in the tag it just fetched. I guess this sort of thing was going on before, but it wasn't displayed, so I wasn't confused.
By the way, I thought there was a PR for sorting tags by semantic version. It's needed.

[scott2000]

My confusion is with the new messages from fetch about abandoned commits, where the description is "release: 0.38.0", which I assume would be in the tag it just fetched.

Since the jj repo uses rebases to merge PRs, this leads to the old pre-rebase commits showing as abandoned when the PR branch is deleted. You can tell this is the case because it's showing as (divergent), meaning there's already another commit with the same change ID (the one that was rebased onto main).

By the way, I thought there was a PR for sorting tags by semantic version. It's needed.

Until that's implemented, you could sort by committer date instead. It should be similar ordering. This can be done with the --sort option or the ui.tag-list-sort-keys config option I believe.

[dragonmaus]

Is there any rationale for or discussion about the configs being moved to an external directory? That seems like a strict regression, as it puts part of the repository out-of-band, causing issues for synchronization/backups and leaving remnants that have to be manually cleaned up when a repo is deleted. I also noticed that the "hashed" folder name (under .jj/config/repos) is different for every clone, even if it's the same repo and in the same location. This just exacerbates the synchronization issues.

I did look through the commits leading up to v0.38.0, but was unable to locate where the change was made.

[dragonmaus]

Interesting, thanks for the links.

It does seem like a bit of a lark, however. Do people commonly share repo meta directories with strangers? (As opposed to the normal DVCS methods of cloning et al.) The only use case I've ever had for copying .jj or .git directories is within my own infrastructure, for sync and backup purposes, where I own and control both ends of the transaction.

[josephlou5]

Same. All my repos are local, so this sort of security concern doesn't really apply to me. I am a little sad that my ~/.config/jj folder is more cluttered now :( And that a config file is created right after a repo is cloned :((

[PhilipMetzger]

It does seem like a bit of a lark, however. Do people commonly share repo meta directories with strangers? (As opposed to the normal DVCS methods of cloning et al.) The only use case I've ever had for copying .jj or .git directories is within my own infrastructure, for sync and backup purposes, where I own and control both ends of the transaction.

The problem is that we at some point will have shared config in the repo itself and the work was done in preparation of that.

[martinvonz]

Do people commonly share repo meta directories with strangers?

I don't think it's common, but if it does happen that someone shares a Git repo with someone else, that other person would probably not know that it's unsafe to run git commands in that repo. We don't want to expose jj users to the same risk.

[dragonmaus]

Ah, I see! Those do cast it in a more understandable light. Shame about the mess that it leaves, but it seems that people are already looking into that.

I'm guessing that the randomization of the path is an additional security measure, then?