What about a jj transaction subcommand?

[AZMCode]

I have often made scripts to extend the functionality of jujutsu with new subcommands.

This often requires putting many jujutsu invocations in a script, with some logic/repetition in between.

This works really well, but there's the issue of each operation leaving a separate operation in the op log, which gets really unwieldy really fast if I want to revert.

So I thought maybe a jj transaction begin and jj transaction commit could be useful to group many operations in the op log together, and ensure they can be undone and redone with a single command, maybe even atomically.

So the script could jj transaction begin, do all operations, then jj transaction commit to put them on the op log as a single operation, perhaps even with a custom description.
Finally if the script fails, it can (or maybe jujutsu itself can, depending on how this would be implemented) call jj transaction rollback, to keep the op log clean.

[PhilipMetzger]

see the discussion in #6846 and things it links to and #8437

[PhilipMetzger]

... since we're otherwise exposing parts Git calls "plumbing" which is something I dislike and it makes the project very liable for things users do with it

"Things users do with it" being... Exactly the same things they can do with the regularly exposed commands?

No, jj would likely be repurposed for things it was not intended to which is not great. I'm going to link to a Discord conversation I had on the same topic sometime ago (see this Discord message).

[AZMCode]

I have to say I echo many of the thoughts in favor in the #6663 issue.

[AZMCode]

No, jj would likely be repurposed for things it was not intended to which is not great.

Isn't every program at some point?
It is fundamentally up to the developers to decide if they want to support something or not.

Also, scripting with jujutsu is widespread and positive in the community, as far as I can tell, and the ergonomics of many of the jujutsu commands enable this. (Most commands never failing, custom templates, etc)
I was just thinking it would be better to support existing usecases as best as possible, instead of forcing a community-wide porting of all the existing scripts.
Paving the cowpaths and all.

[AZMCode]

Seen the transcript of your talk, and it appears I am quite late to this topic.

The fact the jj util exec command is going to be deprecated makes me quite sad, but since it appears this is not the direction the project is taking, it appears there is little point in discurssing further about it.

I will probably end up following the scripting language and grouping operations threads, to see if any movement happens in the space.

[PhilipMetzger]

The fact the jj util exec command is going to be deprecated makes me quite sad, but since it appears this is not the direction the project is taking, it appears there is little point in discurssing further about it.

Nothing is final yet, since that will need to be discussed thoroughly (and I'm not maintainer at the moment) but that's the intended goal. Also the discussion on the PR introducing jj util exec also should be interesting to you #4759.