How bookmarks and Git ought to interact

[evmar]

(Disclaimer: relatively new to jj.)

Using jj to work on a project hosted on GitHub I find that bookmarks are clunky, and I think there is a way to simplify them that would make things much less clunky without needing to have any new features related to automatically updating bookmarks.

Currently to push a change to my main branch, I have to first update my local main bookmark: jj b m -r @- main, and then jj git push. Note that, beyond needing a kind of long command, in particular I have to spell out which branch I mean to push.

Now imagine if jj just didn't create tracking local bookmarks, and instead the git push command took the name of the remote branch to push to, something like jj git push -r @- main where main here is the name of the remote branch to update. (It's the same behavior as git push origin X:main which is something I often do in Git anyway.)

This would mean locally jj would still have the main@origin remote tracking bookmark so I could follow what's going on upstream. When it's time to push I would still specify which branch to push, just as we currently do. All together it would mean I just don't have this extra local main bookmark lingering around that I need to manually twiddle before pushing.

(You could even make this more ergonomic by saying that jj git push as a special case for Git interop doesn't push empty commits, which would mean jj git push main would effectively push your current branch to origin's main.)

[joyously]

Would not having the local bookmark affect the fetch?

[martinvonz]

I think this is the jj git push-ref in #4388. The reason to not put it in the existing jj git push is that most of that command's other flags (--bookmark, --change, --revision) can be combined to select which bookmarks to push. Allowing jj git push -r @- main changes the meaning of -r when a positional argument (main in this case) is passed, and it becomes unclear what jj git push -r @- main --bookmark other --change xyz is supposed to mean.

[martinvonz]

You can already stop tracking the remote bookmark with jj bookmark untrack. I think it's useful to allow both modes, so I don't want to remove support for tracking.

[evmar]

Not disagreeing with you, but can you explain how local tracking is useful? As best I can understand if you don't touch them they just stay in sync with the remote tracking bookmark, and otherwise the main reason to touch them is to push(?)

[martinvonz]

I don't use them myself but I know some people do. I think they're often used by new users who are used to having a name attached to commits like they had with git. It's quite common that users use them less and less with time. But I don't want to say that users use them only because they haven't learned "the proper way" yet; there are probably good reasons for using local bookmarks (and having them track a remote).

Another use case is for integrations, such as with code review tools. The push-* bookmarks many of us use with GitHub is a good example. jj git push -c X creates a bookmark for you and pushes that to GitHub. When you then rewrite the commit, the local bookmark gets updated. jj log will tell you with an * suffix on the bookmark that it doesn't match the remote-tracking bookmark's target, to hint that you may want to push your updated version to the remote.

We use similar integration with our review tool at Google. When you send a commit for review, it gets a bookmark like cl/123, which is used very much like the push-* bookmarks.

[evmar]

For branches I've created locally whose state I want to track (like your cl/123 example) it makes total sense to me.

The part I am trying to better understand is about how/why a remote branch ends up as two different local bookmarks. You have foo@origin, which is labelling "our best understanding as to the branch state on the origin", and then foo, which is this second thing.

I think, possibly to answer my own question and looking at a local repo, you don't always get a second local bookmark for every remote bookmark(?). So maybe my underlying confusing comes from adopting an existing git repo that happened to have a smattering of local branches already(?). (And I guess in the simple case of cloning some repo that has a main branch you end up in this state just because Git made a local branch?)

If that's right, possibly my confusion here comes from jj doing something I don't quite follow yet about mapping git-local branches to local bookmarks. (Sorry for all the question marks, I am still learning!)

[martinvonz]

You have foo@origin, which is labelling "our best understanding as to the branch state on the origin",

Correct.

and then foo, which is this second thing.

It represents your local/personal view of where it should be. If you rewrite the commit it points to, the bookmark gets updated. You can of course also move it manually. When you later push it, the remote gets updated from foo@origin to foo.

I think, possibly to answer my own question and looking at a local repo, you don't always get a second local bookmark for every remote bookmark(?).

Right, you can configure whether to automatically get a local bookmark. See https://jj-vcs.github.io/jj/latest/bookmarks/ for more info.

[PhilipMetzger]

Using jj to work on a project hosted on GitHub I find that bookmarks are clunky, and I think there is a way to simplify them that would make things much less clunky without needing to have any new features related to automatically updating bookmarks.

Yes, the project is aware of that and is trying to solve it.

Currently to push a change to my main branch, I have to first update my local main bookmark: jj b m -r @- main, and then jj git push. Note that, beyond needing a kind of long command, in particular I have to spell out which branch I mean to push.

There's also the idea of using Topics for Git branch interop, which would match the behavior of having a sticky main branch.