jj git push --allow-new by default or not

[yuja]

(Extracted from #4871 so the issue won't be buried)

29a2247 changed jj git push to not create and track new remote bookmarks by default, for the reason described in the commit message. Apparently, the new behavior is too strict for certain use cases.

Should we

• revert the change?
• make it configurable? (it's basically git.auto-local-bookmark for the remote)
• enable --allow-new based on the number of the configured remotes?
  cli: git push: do not push new bookmarks by default #4871 (comment)
• add --allow-track-new instead? (non-tracking local bookmark can be pushed to new remote, but tracking one won't by default)
  cli: git push: exclude new bookmarks tracking other remotes if no --remote set #4730 (comment)
• allow jj bookmark track <name>@<new-remote> to flag new bookmarks to be pushed?
  cli: git push: do not push new bookmarks by default #4871 (comment)

Previous discussions:

• cli: git push: exclude new bookmarks tracking other remotes if no --remote set #4730
• cli: git push: do not push new bookmarks by default #4871

Related:

• private-commits setting prevents pushing allowed bookmarks #5053 (I think the user wants to keep some bookmarks local.)

[BatmanAoD]

Any of the first three bullets seems reasonable to me, especially the one to make the behavior depend on the number of remotes, since I haven't seen a rationale for imposing this restriction when there's only one remote, which I suspect is the common case.

I don't understand the --allow-track-new suggestion; but upthread, it looks like the original suggestion was to permit using an explicit --remote, which does makes sense.

jj bookmark track doesn't seem like a solution to the --allow-new inconvenience, but I'll comment anyway. It seems a bit odd because that's the command used to track an existing branch. Maybe it's fine for it to effectively mean both "track an existing remote branch" and "create a remote from an existing local branch", i.e., "find where this branch exists and then ensure it exists in the other place as well." I think the proposed behavior is analogous to git branch --set-upstream-to (and --track and --set-upstream), but I don't know if similarity to git is desirable in this case.

[steveklabnik]

I thought the original behavior made the most sense, and will end up typing --allow-new in basically all cases. So allowing it to at least be configurable would be nice.

[yuja]

the --allow-track-new suggestion

Any new local bookmarks can be pushed to new remote by default, but if the bookmark is already associated with other remotes, --allow-track-new is required.

% jj bookmark create foo
% jj git push  # will push "foo" to the default remote (e.g. "origin")
% jj git push --remote other  # won't push "foo" because it's associated with the "origin"
% jj git push --remote other --allow-track-new  # will push "foo" to "other"

I think it works better than changing behavior based on the number of the configured remotes. The downside is that it's harder to understand/explain what --allow-track-new would do than --allow-new. (FWIW, --allow-new would have to be renamed if the default depends on the number of the configured remotes.)

[martinvonz]

I thought the original behavior made the most sense

@steveklabnik, do you mean the explicit --remote argument? Or the behavior before (in 0.23.0)?

[steveklabnik]

@martinvonz

My usage of bookmarks is basically only for interop with git remotes, so creating and then pushing them is the sort of default action. That being said, I also probably did not run afoul of the issue that motivated the change because I rarely work on projects with multiple remotes at the moment, and the ones I do, I do want them pushed everywhere.

This change, for example, breaks my tutorial; we create a repository on github that's empty, and then push our local project up to it; this now requires --allow-new.

That being said, I like @yuja 's suggestion above a lot. I think it retains the simplicity of the simple cases while still catching the original problem.

[chriskrycho]

Concur strongly with @steveklabnik here. While I think the multiple-remotes approach I suggested was a reasonable compromise, I like @yuja’s suggestion here better than what I proposed—it makes the easy case easy, and should prevent most of the weird/possibly-dangerous scenarios that the original was trying to prevent.

I do also think some degree of configurability/tunability could be nice? But that seems separate.

[martinvonz]

Sounds good to me too.

[chriskrycho]

@yuja are you planning to implement this? If not, I may have time to take a swing at it over my Christmas break.

[yuja]

@yuja are you planning to implement this?

Yes, I'll basically need to restore the original patch from #4730. If there aren't any other comments, maybe I'll do next week.