Updating a shallow clone of Linux: "graph has cycle"

[MostAwesomeDude]

Description

A shallow clone of torvalds/linux was started near Linux 6.12 and a patch was placed at the tip. Two attempts were made to pull Linux 6.18 for rebasing. Both attempts ended in the "graph has cycle" error. After using git in the second attempt, now all jj commands on the repository yield "graph has cycle" too; the repository is effectively broken.

For what it's worth, I can get things done with git alone. This was one of many experiments I've done with jj and the first time that I've run into this problem. I figure that you might want to know about it.

Steps to Reproduce the Problem

1. Shallow-clone torvalds/linux at tag v6.12 with ten or so commits; the bottom commit should be commit a5ca1dc46a6b610dd4627d8b633d6c84f9724ef0 (grafted) and the git remote should be named gh
2. Either jj git fetch or git fetch v6.18 followed by jj bookmark track v6.18@gh
3. In the former case, failure; in the latter case, the repository is now unusable.

Expected Behavior

I'm a little bummed that jj git fetch v6.18 doesn't work, but one of the two attempts should have yielded a new branch pointing at the upstream commit. Ideally the repository would be in a working state so that I can rebase a kernel patch; that was the bigger goal here.

Actual Behavior

The following terminal session has been lightly edited for readability; I removed tmux formatting.

[simpson@jervis:~/linux]$ jj
@  ymyxklml cds@corbinsimpson.com 2025-12-28 19:51:40 badram a5fb7058
│  Try respinning BadRAM for Linux 6.12.
◆  unvvuwpy torvalds@linux-foundation.org 2024-11-17 14:15:08 v6.12 git_head() adc21867
│  Linux 6.12         
~

◆  rssllmqo torvalds@linux-foundation.org 2025-12-24 09:23:04 master ccd1cdca
│  Merge tag 'nfsd-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux                                                                                                                                
~ 

[simpson@jervis:~/linux]$ jj git fetch
Hint: Fetching from the only existing remote: gh
remote: Enumerating objects: 11330460, done.
remote: Total 10618517 (delta 8976469), reused 10273973 (delta 8635437), pack-reused 0 (from 0)

thread 'main' (22799) panicked at lib/src/repo.rs:1650:25:                                                
graph has cycle
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

For attempt two, I tried using git fetch to get the remote pack first.

[simpson@jervis:~/linux]$ git fetch gh v6.18
From https://github.com/torvalds/linux
 * tag                         v6.18      -> FETCH_HEAD

[simpson@jervis:~/linux]$ RUST_BACKTRACE=1 jj bookmark track v6.18@gh

thread 'main' (400391) panicked at lib/src/repo.rs:1650:25:
graph has cycle
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: jj_lib::repo::MutableRepo::add_heads::{{closure}}
   3: jj_lib::dag_walk::topo_order_reverse_ord_ok
   4: jj_lib::repo::MutableRepo::add_heads
   5: jj_lib::git::import_some_refs
   6: jj_lib::git::import_refs
   7: jj_cli::cli_util::WorkspaceCommandHelper::maybe_snapshot_impl
   8: jj_cli::cli_util::CommandHelper::workspace_helper_with_stats
   9: jj_cli::cli_util::CommandHelper::workspace_helper
  10: jj_cli::commands::bookmark::cmd_bookmark
  11: jj_cli::commands::run_command
  12: core::ops::function::FnOnce::call_once{{vtable.shim}}
  13: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
  14: jj_cli::cli_util::CliRunner::run
  15: jj::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[simpson@jervis:~/linux]$ jj

thread 'main' (400404) panicked at lib/src/repo.rs:1650:25:
graph has cycle
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[simpson@jervis:~/linux]$ RUST_BACKTRACE=1 jj

thread 'main' (400416) panicked at lib/src/repo.rs:1650:25:
graph has cycle
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: jj_lib::repo::MutableRepo::add_heads::{{closure}}
   3: jj_lib::dag_walk::topo_order_reverse_ord_ok
   4: jj_lib::repo::MutableRepo::add_heads
   5: jj_lib::git::import_some_refs
   6: jj_lib::git::import_refs
   7: jj_cli::cli_util::WorkspaceCommandHelper::maybe_snapshot_impl
   8: jj_cli::cli_util::CommandHelper::workspace_helper_with_stats
   9: jj_cli::cli_util::CommandHelper::workspace_helper
  10: jj_cli::commands::log::cmd_log
  11: jj_cli::commands::run_command
  12: core::ops::function::FnOnce::call_once{{vtable.shim}}
  13: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
  14: jj_cli::cli_util::CliRunner::run
  15: jj::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[simpson@jervis:~/linux]$ RUST_BACKTRACE=full jj

thread 'main' (400435) panicked at lib/src/repo.rs:1650:25:
graph has cycle
stack backtrace:
   0:     0x5647d9c391fc - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h5a7965721e20362f
   1:     0x5647d9c79faf - core::fmt::write::hb2be3bc45c2132e7
   2:     0x5647d9c53c4d - std::io::Write::write_fmt::hefe7258ac2f8f77a
   3:     0x5647d9c352e3 - std::sys::backtrace::BacktraceLock::print::hf8c144f475d7afb9
   4:     0x5647d9c4e50c - std::panicking::default_hook::{{closure}}::h20495c8c5cc77186
   5:     0x5647d9c4e3ec - std::panicking::default_hook::h26df0833967641ff
   6:     0x5647d9c4e771 - std::panicking::panic_with_hook::h88667df88367c84a
   7:     0x5647d9c363b6 - std::panicking::panic_handler::{{closure}}::hc49779adfcdeb73f
   8:     0x5647d9c353f9 - std::sys::backtrace::__rust_end_short_backtrace::ha021440587b8be26
   9:     0x5647d9c49d5d - __rustc[bd3b3f48d2381c32]::rust_begin_unwind
  10:     0x5647d8dbb210 - core::panicking::panic_fmt::h4594a04b5e6b3550
  11:     0x5647d8d8d322 - jj_lib::repo::MutableRepo::add_heads::{{closure}}::h9ceaf66b3f7d142a
  12:     0x5647d978d8b6 - jj_lib::dag_walk::topo_order_reverse_ord_ok::h749ad324e8adea4c
  13:     0x5647d971d5f4 - jj_lib::repo::MutableRepo::add_heads::h8fd06299277b5032
  14:     0x5647d96e4ede - jj_lib::git::import_some_refs::hbb4190dd73366378
  15:     0x5647d96d8080 - jj_lib::git::import_refs::hd239858b17d78389
  16:     0x5647d909d2f8 - jj_cli::cli_util::WorkspaceCommandHelper::maybe_snapshot_impl::h7d1f0515540dd655
  17:     0x5647d9087ad7 - jj_cli::cli_util::CommandHelper::workspace_helper_with_stats::hb7aa1c5994c60799
  18:     0x5647d908154c - jj_cli::cli_util::CommandHelper::workspace_helper::hf9c080495325fabb
  19:     0x5647d91215f8 - jj_cli::commands::log::cmd_log::h0b926ee774ac6d84
  20:     0x5647d90c3510 - jj_cli::commands::run_command::h3040d77bb4b74049
  21:     0x5647d8ea9760 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hd36413beddfacaf1
  22:     0x5647d92e6b85 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hc160128ce763408b
  23:     0x5647d90bd582 - jj_cli::cli_util::CliRunner::run::h0ce8c42fcd5516af
  24:     0x5647d8dbb461 - jj::main::h4cb24fbe5cd8ff85
  25:     0x5647d8dbb483 - std::sys::backtrace::__rust_begin_short_backtrace::hcc58e62056a68178
  26:     0x5647d8dbb479 - std::rt::lang_start::{{closure}}::hdb401a1cae6fdde4
  27:     0x5647d9c4b2a5 - std::rt::lang_start_internal::he65b8a7486903d75
  28:     0x5647d8dbb4c5 - main
  29:     0x7fa6f322a4d8 - __libc_start_call_main
  30:     0x7fa6f322a59b - __libc_start_main_alias_1
  31:     0x5647d8dbb355 - _start
  32:                0x0 - <unknown>

Specifications

• Platform: NixOS 25.11
• Version: jj 0.35.0

[yuja]

Can you try with jj 0.37? If you have large Git pack files, decompression could fail.
#8350

[MostAwesomeDude]

With jj 0.37.0 the issue is no longer reproducible. I opened up a Nix shell using upstream nixpkgs and tried asking jj for the state of the tree. Perhaps the output will be informative as to how badly I messed up my tree; it's a legal tree, just somewhat twisted:

[simpson@jervis:~/linux]$ nix shell github:nixos/nixpkgs#jujutsu

[simpson@jervis:~/linux]$ jj --version
jj 0.37.0
                                                                                                          
[simpson@jervis:~/linux]$ jj                
Reset the working copy parent to the new Git HEAD.                                                        
Done importing changes from the underlying Git repo.
@  poyvptum cds@corbinsimpson.com 2026-01-11 21:52:41 8427668c
│  (no description set)
○  qlpxzuyp cds@corbinsimpson.com 2026-01-08 10:35:07 badram-6.18 40a70702
│  Try respinning BadRAM for Linux 6.18.
│ ◆      rmkxxurw torvalds@linux-foundation.org 2026-01-06 09:12:52 master f0b9d8eb
│ ├─┬─╮  (empty) Merge tag 'nfsd-6.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
│ │ │ │
│ │ │ ~
│ │ │
│ ~ │  (elided revisions)
├─╯ │
│   ~  (elided revisions)
◆   │  qxxuszmw torvalds@linux-foundation.org 2025-11-30 14:42:10 v6.18 7d0a66e4
│   │  Linux 6.18
~   │
    │
○   │  ymyxklml cds@corbinsimpson.com 2025-12-28 19:51:40 badram a5fb7058
├───╯  Try respinning BadRAM for Linux 6.12.
◆  unvvuwpy torvalds@linux-foundation.org 2024-11-17 14:15:08 v6.12 adc21867
│  Linux 6.12
~

I'm no longer blocked and can continue transitioning from git to jj in my workflows. Feel free to keep this issue open and ask me for more details if necessary, but I am satisfied for now. Thanks for your hard work!