FR: Improve default behavior of `jj bookmark track`

[senekor]

Problem description:

The new behavior of jj bookmark track <name> (without --remote) tracks the bookmark with all remotes. I think this is a bad default in the most common situation:

When contributing with one's own fork, the remotes are often named origin and upstream. Pushing to upstream is not possible, only to origin. When creating a new bookmark and tracking it with jj bookmark track <name>, the bookmark would be tracked with upstream as well, which is bad.

It has also been pointed out that the current behavior of jj bookmark track is not idempotent, which is weird. (If foo@origin exists, the first run will only create the local foo, ignoring other remotes. The second call will track foo@*.)

Possible solution:

I mainly want to start the discussion, but here's a suggestion that seems intuitive to me:

• If there is at least one remote where a matching (untracked) bookmark already exists: track the bookmark with all of those remotes.
• If the bookmark is already tracking something and there is no remote with a yet-untracked matching bookmark: Do nothing except print a hint to specify --remote.
• If the bookmark isn't tracking anything and no matching remote bookmark exists: absent-track the bookmark with the default remote.

Possible alternatives:

Assume this situation: local foo, foo@origin and foo@upstream exist. Only foo@origin is tracked. With my above suggestion, jj bookmark track foo would also track foo@upstream. I thought about making that a no-op instead. So, if a bookmark is already tracking anything, always require --remote to track any additional remotes. I decided against this, because I couldn't think of a situation where I wouldn't want to track the matching bookmark on other remotes as well. Also, it would be impossible (?) for the user track "all remaining remotes where a matching bookmark already exists", because there is no string pattern to express that.

cc @yuja @martinvonz @PhilipMetzger

[yuja]

I think these two are different operations even though they update the same variable:

1. track existing remote bookmark
2. set up tracking of exiting local bookmark for pushing

For 1, we merge remote changes in to the local bookmark, and new local bookmark is usually created as a result. For 2, the user wouldn't expect that the local bookmark may be updated.

If these two are different subcommands, I think we can find better defaults. I think the current default --remote=* is good for tracking existing remote bookmarks. There should usually be one remote matching the bookmark name. Maybe the default for "2. tracking for pushing" can be similar to jj git push --bookmark?

[senekor]

The way I think about it, jj bookmark track means: "I want to modify this bookmark and push it to a remote to share my work with others." That applies to both 1 and 2, so I personally don't think two separate commands are necessary. Though, I wouldn't mind it much either. And admittedly, this FR becomes much easier if there are separate commands.

Maybe the default for "2. tracking for pushing" can be similar to jj git push --bookmark?

That sounds good, yes. Although, for jj git push --bookmark, --remote intentionally doesn't do anything. That would have to be different for the new command, I suppose. What to call it? ideas:

• jj bookmark mark-pushable
• jj bookmark intend-to-push
• jj bookmark track --absent
• jj bookmark track --new

There is a recurring idea to add a flag to jj bookmark create that would also setup absent-tracking in one operation. It might be good if that loosely matches this new command. e.g. jj bookmark create --intend-to-push or jj bookmark create --track, depending on what we choose. Just something to keep in mind.

[yuja]

There is a recurring idea to add a flag to jj bookmark create that would also setup absent-tracking in one operation. It might be good if that loosely matches this new command. e.g. jj bookmark create --intend-to-push or jj bookmark create --track, depending on what we choose.

Yes. If we add jj bookmark create --intend-to-push=REMOTE, it might make sense to add jj bookmark track --intend-to-push=REMOTE (which would conflicts with the --remote=REMOTE argument.)