Better generated branch names with jj
36 points by pushcx
36 points by pushcx
will share something I think has worked well for me, in terms of "adding metadata to commit messages then using it"
First, an alias to easily get a trailer value from a commit description:
[template-aliases]
'trailer_v(key)' = 'stringify(
if(trailers.any(|t| t.key() == key),
trailers.filter(|t| t.key() == key).first().value(),
""))'
^ this lets me refer to git trailers easily in git messages
in a nushell script I then use to push this up I then build up the bit branch as follows:
$label_to_use = (
jj log -r $revision -T 'trailer_v("ticket").lower() ++ "/" ++ trailer_v("topic")' -G
)
In a commit I can put something like:
fix: stop crashing when doing a thing
we shouldn't crash when doing the thing
ticket:TKT-123
topic:stop-crashing
and that'll get pulled in with the script I use to push up to Github then open up the "Create PR" page.
Anyways git trailers are a nice k/v store in descriptions that can be pretty consistently used. Just a bit annoying to pull out in the current revset language
This feels like low hanging fruit for a local LLM to slugify the branch name based off the commit message / contents.
Why would you use an LLM for this instead of the simple script in the article? The script is lighter weight, probably faster, and seems like it would work just about as well.
The approach in this article seems to assume that the bookmarkâs tip changeset is a good summary of everything reachable from that bookmark but not already on the target branch.
That breaks down when the bookmark points to a stack of changesets. For example, if there are three changesets on top of the merge base and the tip is something like chore(blah): fix typo, the generated bookmark might be username/fix-typo, even though the branch is really about the feature implemented in an earlier changeset.
With even a basic LLM workflow, you could pass a jj revset covering the changesets being pushed and ask it to distill their descriptions into a meaningful slug for the whole bookmark. Trying to do the same purely in the template would likely produce noise and the result would be heavily influenced by changeset ordering rather than by the overall intent of the branch.