FR: jj git push -b should imply -N when there is only one remote

[Zambito1]

Is your feature request related to a problem? Please describe.

The -N flag seems to have been added to avoid unwanted pushes to multiple remotes (see: 296961c). When using a single remote though, this is less convenient.

Describe the solution you'd like

When pushing to a single remote with -b, I always want -N to be implied. This would restore the previous behavior when using a single remote.

Describe alternatives you've considered

Maybe making a configuration option (that could be set at a repo level) to always imply -N.

Additional context

N/A

[PhilipMetzger]

I think this should be solved by the next release, see the discussion in #5094 and its solving commit f9906dc. I'm leaving it open so a maintainer or Yuya can respond though.

[ilyagr]

I am not sure this is fully resolved (though I think the urgency should be much decreased by f9906dc).

I have not followed the entirety of #5094, but naively, some possible additional steps I could imagine taking are:

1. Document a suggestion to run jj git config set --repo git.push-new-bookmarks true in single-remote repos.
2. Make git.push-new-bookmarks a tri-state, with an additional unique-remote setting. Another possible setting I can imagine is a list of remotes to allow pushing to.

I'm not suggesting that either is necessarily a great idea (in fact, I don't really like option 1, since a repo with one remote can get another remote added later), but I think we might want to have a discussion of whether something like 2 is reasonable.

It makes perfect sense to me to keep #5094 closed and have a separate thread for further fine-tuning.

At the same time, some people might want a bit of a break before looking at this issue again. A break is also good for people to have time to try out the new option and see how it works for them.

[ilyagr]

I'm also wondering whether something like #5472 will help. I almost have a prototype for that done, though I'm not 100% confident in the design or that we'll end up merging it.

[yuja]

I personally don't think there's low-hanging fruit to address #5094. It would be surprising if the behavior changed depending on the number of configured remotes, by default. It might be okay if user opts in to it, but that means the user has to configure git.push-new-bookmarks anyway. I don't want to complicate this flag and documentation to address small inconvenience.

Things like #5472 might be useful.

[ilyagr]

Fair enough.

To exhaust my comment above: I mentioned it only in passing, but WDYT about the idea of allowing git.push-new-bookmarks to take a list of remotes, e.g. ["origin"]? I imagine that this could be useful, especially for repo config, but maybe also for user config.

OTOH, I would not use this myself, and I don't know that we had requests for this exact behavior.

[yuja]

allowing git.push-new-bookmarks to take a list of remotes, e.g. ["origin"]?

It might be good to make both push-new-bookmarks and auto-local-bookmark take string patterns if there are demands for. It might be also good to add per-remote table for various push/fetch options. I wouldn't use them either, btw.