[kccqzy]

You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions.

That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and deletes remote git branches (`jj git push -c` for creation, plain `jj git push` for updates, `jj git push --deleted` for deletions). I do not ever have to think about branch names and it is great!

[y1n0]

Yeah, I don't get it. I'm sure it's because we work differently and that's fine.

But when I'm picking up something someone on the team has left behind because they got pulled on to something else, or are sick, or 5 million other reasons, having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters. I can't help but think that everyone that likes JJ isn't really doing collaboration.

[kccqzy]

I collaborate a whole lot. In fact for solo development I use git because jj is overkill for it. Also by default jj prevents you from overwriting commits that exists on the main branch on the remote, but this is what I often do on solo projects.

> having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters

In my view, all the above information exists not in the branch name, but either in the ticket, or in the commit message. The branch name is purely a superfluous thing that does not convey any information. Many of my colleagues already use a tool to automatically name their branches from the first line of their commit messages, and jj just makes this awkward process straightforward.

[Macha]

When its MR time I use jj push -c and I’ve set my config to auto generate a branch name from the commit message by extracting the ticket ID from the commit message since we have a standard format into something like PROJ-1234-nzytopmn . Since the company I work at enforces squash merge since many coworkers would otherwise have 20 merge, fixup, lint or ci fix commits per MR, auto advancing isn’t relevant. Addressing comments is just squash into that change and repush. We don’t really do long lived branches so the ticket number is enough to find the branch and the commit message explains the change if I need to hand over work.

[dzaima]

But 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.

[kccqzy]

> 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.

[dzaima]

> It is like writing out a plan for what I want to do.

I usually don't have a plan for the end; certainly not what any specific commit would be; sure, I could make one (and either make my future self have to do extra work to figure out what commits with lies in their descriptions actually do, or continuously update the commit message marking what actually exists), but as I said that's basically a waste of time. (if you like comparing with past thoughts, sure, but that's definitely not a necessity for a workflow to be reasonable)

"is/isn't an ancestor of the bookmark" is also just a pretty damn good short-hand for denoting a separation between what's been considered the best attempt at the goal, vs things with known problems or just unrelated to the task.

At the core, this if all of course just a question of workflow; if you go into a thing with a plan, meaningful outlook of a non-vague destination, and without expecting continuous switching back&forth between a dozen other things over the time span the branch is alive, caring less about branches or branch names can perhaps work.

> The first line of a commit message is already a summary of the work done.

But you can't (sanely) use it to reference the branch in a revset, can't find it anywhere other than the full log (that's interleaved and mixed with a bunch of other things that you won't ever need to search for), and actual English just gets in the way for finding it, remembering it, and identifying it in a list.

This alone means that, even if I found interest in massively-ahead-of-time-describing commits, having a sane branch reference is still simply just necessary.

[rixed]

  branch names are just a summarization of your commit messages

What kind of dev workflow leads to this surprising opinion?

[cpeterso]

I name my branches for the overall task. The description of the branch’s head commit in jj status doesn’t tell the whole story.

[kccqzy]

Ah but then I reword the commit message as I make changes to the commit. If the commit message does not tell the whole story, I change the commit message. It's much more convenient to change a commit message in git than to rename branches, so branch names tend to be more out of date than commit messages.

[krackers]

>You don’t need easy named branches.

You can't possibly see a use-case for long-lived branches? Say what you will of git, at least it exposes enough knobs that it can mostly accomodate every workflow (possibly with a heavy porcelain layer to hide the plumbing). JJ seems to swing too far in the other direction, great for a "live on head" mentality but less ideal for other setups.

(The fact that all edits are automatically recorded is my personal peeve with JJ. I'm ok with lack of staging area like in Mercurial, but mercurial doesn't try to automatically amend the commit with my pending changes. Sure I can pretend that "@" is my staging commit then squash as needed, but then I also need to remember that checking out a commit is "jj new" which feels like absurd mental gymnastics to me.)

[simonmic]

You can turn off auto-tracking.

[krackers]

Last i checked that only disables tracking of new files, it doesn't do anything to prevent the "auto-amend" behavior for modified files.

[kccqzy]

Honestly it took me about two days before I just got used to it. You can change `git checkout blah` into `jj new blah`.

[kccqzy]

Oh and one more thing I forgot: in git a lot of operations require you to have a clean checkout. Otherwise you have to stash your changes first before doing that operation. With jujutsu’s model, there is no stashing. Every edit is already part of a commit. Therefore you can totally do rebases even when you are in the middle of some other unrelated change.