programmatic status output (json?) (akin to git porcelain)?

[colemickens]

Hi,

I am playing with starship-rs and trying to add gitstatus support. But also, I could see myself moving all of my git usage to jj, and the model of updating --no-commit-working-copy means that getting status from jj can be very fast without needing the complexity of gitstatus/gitstatusd.

So, I'm considering just jumping to implementing jj support in starship instead.

Question: should I just pull in jj's lib via Rust? Is it (going to be) stable enough to do start down this path?

Or should I try to parse jj status --no-commit-working-copy or is there room for a jj status --no-commit-working-copy --{tsv|json} to output programmatic status information? Or maybe the jj status output is rich/simple/fixed enough that I can just parse the lines of it directly?

[martinvonz]

Mercurial has something called called which I hope to copy to jj. jj log already has support for templates, but I don't consider the format stable (I experimented with something different from Mercurial's syntax because I wasn't happy with that, but I'm not happy with my syntax either :)).

The library is probably stable enough that it won't be much of an issue to use it. I suppose I'd have to release a new version to crates.io then, unless you're okay with pointing to a specific commit in this repo. However, the biggest drawback of using the library is probably that it would not be upgraded at the same time as the jj binary, which means that any format upgrades made by the binary could make the library unable to read the repo. In the long term, that kind of compatibility issues means that we shouldn't automatically upgrade the repo, but it's been convenient to be able to do it so far. For context, the most recent upgrade moved a bunch of subdirectories from .jj/ into .jj/repo/.

So I would probably parse the jj status output for now. To be able to do that, we'll need at least a --color=never option or similar, so it doesn't depend on the user's config. Other than that, the only little format change to the output I've considered is to remove the space before the colon in "Working copy :". It's there to make it aligned with the "Parent commit:" line above. Maybe that's enough reason to not change it?

FYI, what I miss most from git is:

• Path-restricted log (git log some/dir)
• Blame
• Rename detection when diffing and merging

So keep that in mind when you decide whether to switch. I usually fall back to GitHub's UI for those features for now. You can also do things like git --git-dir=.jj/repo/store/git blame origin/main README.md, which is not terrible if you set up an alias.

[arxanas]

Mercurial has something called called which I hope to copy to jj.

It has something called what?

[martinvonz]

lol, I don't even know what I meant there. Maybe I meant "templates", but I then say that jj log already supports it, so maybe I meant something else. I don't know what other than templates would be relevant here, though.

[tcoopman]

I'm looking into starship custom https://starship.rs/config/#custom-commands
And was trying to use templates to create a useful output.

I was wondering if I can pass either a template into jj diff --stat or use jj log -T to reformat the x files changed, y insertions(+), z deletions(-)

If I could do that and combine it with a template on the log, I think the custom command could be very useful already

[martinvonz]

We don't have support for either of those yet. I'm not sure how I think we would do it best even if we were to do it. I suppose you can work around it by creating a tiny script that just runs jj diff --stat | tail -1?

[jbcdnr]

Is there any update on something like --format json to be able to use jq instead of the template language? Also found this related issue #3814

[arxanas]

I believe no one has been working on this. You could propose a design/implementation if you like.

Vaguely speaking, there might be a preference to write something like -T 'whatever.json()' rather than literally --format json (but maybe that doesn't work to dump e.g. an entire log/commit graph).

[PhilipMetzger]

also related #3262 (comment)