but status returns error when there is a new branch

[stijnvanderlaan]

Version

0.19.9

Operating System

macOS

Distribution Method

dmg (Mac OS - Apple Silicon)

Describe the issue

Getting an error, when running but status: head_info does not contain segment that graph has

How to reproduce (Optional)

1. Stage a file on a new branch
2. run but status

Expected behavior (Optional)

I expect to get a normal status report

Relevant log output (Optional)

[Byron]

Thanks a lot for reporting!

The error originates here:

gitbutler/crates/but/src/command/legacy/status/mod.rs

Line 726 in cd82c6b

.context("BUG: head_info does not contain segment that graph has")?;

And that line was recently changed. @jonathantanmy2 might have an intuition on what's going on here - it looks like stale data, but it's hard to imagine how this can happen within a but invocation.

[jonathantanmy2]

Hmm...I'm not sure how this could happen. We have a test for an empty branch (status_shows_no_commits_label_for_empty_branch) and looking at the code, both but_workspace::head_info (used to create the "head_info" mentioned in the error message) and Context::workspace_from_head (used to create the "graph" mentioned in the error message) create their respective data structures from HEAD, so there's no issue of having different scopes of information. Looking at how but_workspace::head_info creates its data structure, there are also no segments being filtered out (see try_from_graph_stack in crates/but-workspace/src/ref_info.rs).

Do you have a more concrete reproduction? E.g. show what but status --files is before you stage a file on a new branch, and also include the command you used to stage a file on a new branch.

Having said all that, if the branch is empty, this segment information is only used to show CI information. I'll downgrade this fatal message to a warning printed to stderr. If this becomes more pervasive, it will still be caught by our but status tests (which all assert that nothing is printed to stderr) and will make status still work. I'll send out a PR soon.

[atreidesend]

fyi - I just ran into this as well (on my mac device), worked around it by using the UI to commit to the new branch before resuming any CLI usage

[stijnvanderlaan]

Hey @jonathantanmy2 I’m staging the file through the GitButler UI rather than using the CLI.

[Byron]

I think this might be fixed already, it can be tried in the Nightly release.

[jonathantanmy2]

Hey @jonathantanmy2 I’m staging the file through the GitButler UI rather than using the CLI.

Ah, thanks. I'm not sure if the UI is doing anything strange here, but staging to an empty branch via the CLI works, as you can see in this passing test:

diff --git a/crates/but/tests/but/command/rub.rs b/crates/but/tests/but/command/rub.rs
index f96fc5b87d..c4ee42d831 100644
--- a/crates/but/tests/but/command/rub.rs
+++ b/crates/but/tests/but/command/rub.rs
@@ -189,6 +189,40 @@ j0 a.txt│
     Ok(())
 }
 
+#[test]
+fn mytest() -> anyhow::Result<()> {
+    let env = Sandbox::init_scenario_with_target_and_default_settings("two-stacks-one-empty")?;
+
+    env.setup_metadata(&["A", "B"])?;
+    env.file("a.txt", "arbitrary text\n");
+    env.but("zz:a.txt B").assert().success();
+
+    env.but("status --files")
+        .assert()
+        .success()
+        .stderr_eq(snapbox::str![])
+        .stdout_eq(snapbox::str![[r#"
+╭┄zz [unassigned changes] (no changes)
+┊
+┊╭┄g0 [A]
+┊●   9477ae7 add A
+┊│     94:tm A A
+├╯
+┊
+┊  ╭┄l0 [staged to B]
+┊  │ ku A a.txt
+┊  │
+┊╭┄h0 [B] (no commits)
+├╯
+┊
+┴ 0dc3733 [origin/main] 2000-01-02 add M
+
+Hint: run `but diff` to see uncommitted changes and `but stage <file>` to stage them to a branch
+
+"#]]);
+    Ok(())
+}
+
 #[test]
 fn uncommitted_file_to_unassigned() -> anyhow::Result<()> {
     let env = assigned_uncommitted_file_env()?;

But in any case, as @Byron says, I've downgraded it to a warning so you should be able to run but status from now on (albeit with a warning message).