alt Hacker NewsBut you probably haven't spent time writing commit messages before a branch is finished. Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change; replacing a chore with a much bigger chore.
Restricted and summarized is good - easier to find/remember, less fluff in a list. And easier to recognize a short identifier from a list of the 2-3 most recent branches, than scanning through 50 commits, when trying to remember where some work last was, and which is the proper end-point instead of some failed attempt or unrelated change.
Unnamed branches are quite neat - I certainly have a lot more of such than named ones in jj - but as such named branches are, if anything, more important as a result, for separating sequences of changes striving towards a goal, from the sea of smaller experiments.
> But you probably haven't spent time writing commit messages before a branch is finished.
Wrong. With jj, I use `jj describe` before I start work. It is like writing out a plan for what I want to do.
> Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change.
Rewriting it is not wasted time. It is an opportunity to look at what I have written in the plan and check whether I have really executed them, and then rephrase things to be more easily understandable.
> Restricted and summarized is good - easier to find/remember, less fluff in a list.
The first line of a commit message is already a summary of the work done. And you can use actual English instead of trying to awkwardly avoid spaces in your words.