Explain why Jujutsu does not have a concept of a "current bookmark"

[9999years]

The FAQ says that:

Jujutsu does not have a concept of a "current bookmark".

However, the FAQ does not explain why this is. What advantages does this confer? Coming from Git, this has always seemed very odd to me. I'm sure there's a good reason for it, but I haven't quite been able to figure out what it is.

[ilyagr]

The first thing that comes to mind is that if you have a PR consisting of several commits A -> B -> C, and you want to edit commit B, you can do jj new B, edit, and then do jj squash.

In Git, you'd have to either 1) create and name a temporary bookmark at B and switch to it or 2) enter the "detached HEAD" state, e.g. git switch --detach B. In Git, this "detached HEAD" state is abnormal, and in fact won't work very well if your goal is to amend commit B (since, in Git, commits that are not on any branch are considered discardable). In jj, it's the normal state to be in.

So, the benefit of not having the current bookmark is that you don't need to create as many temporary branches in such workflows, and that there's no need to have separate "detached HEAD" state. One hope of jj is that it will make it easier for people to edit their PRs to tell a nice story that's easy to understand and review, even if the PR consists of several different steps. So, it's designed to make workflows needed for editing PRs in this way easier.

OTOH, if you only ever need to edit commits that are at the tips of branches, you won't see as many advantages. The danger here is that PRs can become a history of every fixup the author needed to make to the first draft of their work, and this can be difficult for another person to review. This might be more of a problem for some projects/repositories than others; it's not much of a problem for a personal repository that one person is working on, for example.

[9999years]

I understand the benefits of being able to edit history, and I really want to use the tools jj has for (e.g.) splitting a revset into multiple independent changes (jj parallelize). I use a rebase-heavy workflow, so this is very familiar to me.

What I don't understand is how you deal with pushing changes. Is it not ridiculously tedious to jj bookmark move my-bookmark-name before every push? For me, this would mean tabbing over to GitHub or my employer's ticket tracker to copy the branch name every single time, which I am certain would drive me positively batty.

Does this just not bother you? Am I doing something wrong? Do you not push your changes frequently?

[TeofilC]

Is it not ridiculously tedious to jj bookmark move my-bookmark-name before every push?

I think folks tend to use something like this jj tug alias for workflows like this.

I think the other approach is that 1 commit = 1 pr and then you don't need to update your bookmarks

[ilyagr]

Is it not ridiculously tedious to jj bookmark move my-bookmark-name before every push? For me, this would mean tabbing over to GitHub or my employer's ticket tracker to copy the branch name every single time

I agree that this is a downside. Different people have different approaches here. We haven't figured out one perfect solution for everybody that preserves the upsides I described in my original message. However,

• jj tug recommended by @TeofilC helps.
• In complicated cases, jj bookmark move -r might be easier than finding the bookmark's name.
• Dynamic tab completion of bookmark names (or of revsets) helps.
• I mostly end up needing to jj bookmark move when I change my mind about how many commits my final PR will have and what the last commit in that sequence will be. At other times, I create commits without branches and then squash them into already-existing commits that are on a branch. For PRs made of 3 commits, this usually happens at most a few times. For a PR with many commits, the last commit's identity still changes only rarely.
• People seem to be split into two camps. One camp uses jj git push -c which auto-generates bookmark names. I'm guessing they use jj tug to move them, but I'm not sure. I'd call myself a member of another camp. I tend to use jj git push --named to give each bookmark a name that I can easily type or complete when I need to do a jj bookmark move command before a push.
• There exists Implement FR #2338 for current branches / automatically advancing branches #3129, though it has some problems discussed in Feedback for the experimental `advance-branches` feature #3549. Perhaps one day people will figure out how to improve it further.

The one time I can think of when I end up moving a bookmark often is if I'm making a lot of work that's not really meant to be carefully reviewed by somebody else. In these cases, I use jj tug or make sure there's a bookmark with a short name I can easily move to keep up with my work. I'd say jj is s bit less optimized for this kind of workflow than Git is, but it works out OK for me.

[9999years]

Thanks, that's very helpful! I think these tools combined with #6891 will let me build a pretty good workflow.

[emilazy]

What I don't understand is how you deal with pushing changes. Is it not ridiculously tedious to jj bookmark move my-bookmark-name before every push? For me, this would mean tabbing over to GitHub or my employer's ticket tracker to copy the branch name every single time, which I am certain would drive me positively batty.

I feel like maybe there’s a misunderstanding here? If you amend a commit that a bookmark is pointing to, by way of jj squash or jj edit or similar, the bookmark moves with it (for the same reason that the children of the old commit get rebased on the new one: it’s “replacing” the old commit). You only need to explicitly move the bookmark if you want an additional commit in the final history, which is required if you aren’t doing a rebase‐heavy workflow (as you said you are), but otherwise should be relatively uncommon (and you can often e.g. jj split -r X -B X in that case).

[emilazy]

And, to clarify, you don’t need to name a bookmark every time you push, even if you don’t use jj git push -c bookmark names. jj git push will push remote_bookmarks(remote=<remote>)..@ by default.

[9999years]

Thanks, that's also very useful! @ilyagr can I open an issue to track getting this information into the documentation?

[jennings]

Can I turn the question around: Why does git require a current branch?

It's possible to check out an arbitrary commit, it just puts you in a detached HEAD state. So, it's not a hard requirement.

The main reason is that any commit not reachable from a branch is considered "dangling". As soon as you check out a different commit, POOF, it's no longer visible in the log. This is why it's usually problematic to commit with a detached HEAD.

What if git didn't automatically drop dangling commits? What if they remained visible in git log even without a branch?

• You might start using dangling commits more often.
• You might wait to come up with branch names until you needed to push.
• You might rely on the commit descriptions more for understanding what your commits are doing.
• And to make reading the descriptions easier, you might prefer amending commits over adding "fix stuff" commits, so there are fewer commits to scan through.

That sounds a lot like jj to me.

[9999years]

Can I turn the question around: Why does git require a current branch?

Architecturally, Git does not require branches (as you've noted). But once we start interacting with other systems (like GitHub), branch names are very important: they're human-readable (and thus memorable) names for changes.

I don't mind a detached HEAD workflow for the most part. I do mind that jj makes me retype a full branch name every time I want to push to GitHub.

jj users are quick to note, at this point, that jj can automatically generate branch names for you. Unfortunately, I rely on a third-party tool to generate branch names: my employer's ticket tracker. By using the generated branch names (formatted like myname/team-1234-ticket-title), my PRs are automatically linked to the ticket tracker. I do not want to manually link PRs to the ticket tracker for the same reason I do not want to manually type my branch name every time I push.

Pushing is something I do pretty frequently, so I'm not sure this friction is worth it compared to my current workflow (even if jj's history-editing features sound really cool to me!).

What if git didn't automatically drop dangling commits? [...] You might wait to come up with branch names until you needed to push.

Again, I'm not sure if there's something I'm missing here. Programming is collaborative, so pushing my work is generally one of the first things I do — having a permalink to share with coworkers to talk about my architectural approach, share test failures, etc. is very important very early in the process.

[joyously]

I'm not sure if there's something I'm missing here.

Could be something about immutable commits, and how you define immutable(). It seems like your examples are rare and might not belong in a repo.

[jennings]

I don't mind a detached HEAD workflow for the most part. I do mind that jj makes me retype a full branch name every time I want to push to GitHub.

EDIT: I opened this thread on mobile so I didn't see your reply to ilyagr where you clarified you're talking about jj bookmark move <name>. I agree that this feels like an extra step even if you use the tug alias. However, if your workflow involves amending commits rather than creating new ones at the tip of the branch, the bookmark rarely needs to be moved (jj automatically moves it to the amended commit).

Previous reply:

It seems like you want to do the equivalent of git push. jj git push should do something very similar to the "simple" push strategy. In the simple case of jj new my-feature; make_changes; jj squash, running jj git push with nothing specified will push my-feature to the remote. Does that help your use case?

You can also customize what commits jj git push with no arguments will push. By default it pushes any bookmarks in the revset remote_bookmarks()..@, which is a little hard to describe in plain language but means "any bookmarks that have changed in @ and its ancestors, until you reach a commit which is already on the remote". But you could change that to heads(bookmarks() & remote_bookmarks()..@) to only push the "closest" one in that revset.

If jj git push won't work in a specific scenario, you can also jj git push -r xyz to push any bookmarks on change xyz, which is much shorter to type than the whole bookmark name and almost always uniquely identifies a bookmark to push.

Again, I'm not sure if there's something I'm missing here. Programming is collaborative, so pushing my work is generally one of the first things I do — having a permalink to share with coworkers to talk about my architectural approach, share test failures, etc. is very important very early in the process.

I'm not quite sure what you're referring to here. To push, you must create a bookmark either manually or with jj git push -c, so there will always be a bookmark name by the time you are collaborating.

The only difference I see is that jj encourages you to create a bookmark just before pushing while git encourages you to create it before committing.

[joyously]

That FAQ answer might be a case that should not have changed "branch" to "bookmark".
I would consider the @ to be "current bookmark", but not really "current branch".
Since you can edit, rearrange, and abandon commits all over the graph with no special syntax, there is no point in having a "current" anything, except for @.

[9999years]

I thought @ was short for HEAD (just like in Git), not a bookmark. Is that incorrect?

[lf-]

@ is the working tree, not the git HEAD. The parent of @, that is, @-, is the git HEAD in general; when you edit any file it goes directly into @. There's different workflows people use for what they actually keep in @, but it can be a staging area or something else, depending on workflow.

[9999years]

Thanks for the quick answers, all. I was actually requesting that information on this be added to the jj FAQ, but this is perhaps a good starting point.