add CliIds to `but --json status`

[schacon]

[Byron]

I wanted to hand this to AI but I keep thinking that adding Clits isn't the right prompt. Can you elaborate 😅?

[Byron]

Now I get it: A CliId is a short-id of sorts that's only valid in the CLI to refer to items when interacting with them.

[schacon]

Right, like:

❯ but st
╭┄00 [Unassigned Changes]
┊
┊╭┄iy [sc-branch-8]
┊●   733bf8f update styles to be a bit nicer on command pages
┊●   a8dd74f don't delete overview page on import
┊●   6e96b27 create cli overview pages
├╯
┊
┊╭┄jy [sc-branch-9] (no commits)
├╯
┊
● c1e8752 (common base) [origin/main] update rubbing to fix determinism issue

We need the --json output to have iy and jy, which it does not yet have.

[estib-vega]

Little note regarding the fix for this:

https://github.com/gitbutlerapp/gitbutler/pull/11190 Should close this, although there is a weird corner regarding the CLiIDs. I appears that we generate the CLIs from the hunk assignment. This seems to point to the file instead of to the actual hunk.

My guess is that in the future this should be different ids. For now, I'm adding the CLiIDS to all the hunks and see if any one finds it. If they find it after going in circles and up and down the code, then they might arrive to the peak or climax of code understanding. Who knows

[krlvi]

Thinking about this... are we sure this is a good idea? The CLI ids were meant to be an ergonomic compromise for visual/ human consumption. The issue with adding it to the JSON output is:

• they can be ambiguous, and if that happens, any command that takes a CLI id will ask for user input to disambiguate
• they are generated for a particular "status" state

When using the but CLI programmatically, there should be no issue in using full identifiers, and those should be unambiguous and equivalent.

@schacon , with this setup - what is the reason for wanting CLI ids on the JSON api?

[galligan]

@krlvi some details are here, which was a write-up produced by Claude after hammering through some multi-agent concurrent coding experiments.

Essentially the agents naturally wanted to "move" some of the various GitButler-related things (commits, etc.). They all got stuck when trying to figure out the IDs of everything. This resulted in them trying to parse the status output, though not always reliably.

[krlvi]

Oh i see. Btw thank you @galligan for taking the time to test this so thoroughly and for sharing this writeup.

In general, it should be possible to use the long-form IDs for everything when performing rub operations (i.e. the commit sha when referring to a commit, the branch name when referring to a branch).

But I suspect the agent cant figure out what identifier it needs to use... And herein may lie a deeper issue - the JSON output contains a lot of stuff, and I wonder if this could confuse agents in what they are supposed to use.

Have you been able to test a nightly build to see if it helped your use case? I fear that it may not be clear still, especially with the quantity of fields that exist. We could possibly do more on the front of defining JSON schemas that document what the fields are and what should be used when...