Ask for confirmation before pushing to remote

[slerpyyy]

jj git push is one of the few commands that cannot be undone easily using jj undo, so special care is needed to make sure we get it right every time. Currently, the only way to inspect what jj git push is going to change about the remote ahead of time is using --dry-run, though doing this on every push adds a lot of friction to the development process.

This PR adds an option to prompt the user when running jj git push:

Changes to push to origin:
  bookmark: bookmark2 [move forward from 38a204733702 to 88ca14a7d46f]
  bookmark: my-bookmark [add to 88ca14a7d46f]
Continue? (Yn): 

This prompt is configured using the config git.confirm-before-push, which has three possible values: always, never, and auto, the last of which only prompts the user when multiple bookmarks or tags are being pushed at once. The default option is auto; interactions can be skipped using the -y/--yes flag.

(No LLMs were used to create this PR)

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added/updated tests to cover my changes
• I fully understand the code that I am submitting (what it does,
  how it works, how it's organized), including any code drafted by an LLM.
• For any prose generated by an LLM, I have proof-read and copy-edited with
  an eye towards deleting anything that is irrelevant, clarifying anything
  that is confusing, and adding details that are relevant. This includes,
  for example, commit descriptions, PR descriptions, and code comments.

[PhilipMetzger]

I generally don't think we need more flags which hook into the UI and as necaqua previously put it "having jj undo makes having a such options unnecessary".

[slerpyyy]

having jj undo makes having a such options unnecessary

I generally agree with this sentiment, and it's exactly for that reason I'm submitting this PR. You don't need any safe guards on most jj commands, because the ability to quickly & easily undo them is the safe guard; but jj git push instantly affects an external remote, and jj undo can't change that.

[PhilipMetzger]

You don't need any safe guards on most jj commands, because the ability to quickly & easily undo them is the safe guard; but jj git push instantly affects an external remote, and jj undo can't change that.

And since the purpose of this command is to synchronize the local state with the external one, this is something which works as intended. If Git weren't Git and we had a native remote such discussions would be unnecessary since we could have a general mechanism for replaying state updates on the server side.

[joyously]

I kind of like the idea, since there is a big fuzzy area in my understanding of how jj decides what to push.
Perhaps it could be a --verbose flag instead of confirmation.

[PhilipMetzger]

I still wouldn't do this but this has some major implications for which we should respect our users and don't add a breaking change in such a way.

We first should make this opt-in and then warn on the old behavior before just making it interactive for everyone (and only after the warning is removed this could be the behavior).

[ShiroKSH]

Two changes requested: make the confirmation match the signed push, and correct the documented setting name.

[ShiroKSH]

Re-reviewed at 358ec6f. The confirmation now previews the signed targets, the abort path does not persist rewritten commits, and the documented setting name is corrected.

[ShiroKSH]

Author context: @slerpyyy (Aaron Bies, Saarland University); write access, no obvious review-history risk.

Re-reviewed f0eeafc. The new revision keeps the signed targets in the confirmation preview and correctly reports that an aborted push changed nothing. Focused confirmation, signing, and config-default regression tests pass.

[slerpyyy]

I have removed the hint for this feature and set the default for git.confirm-before-push to never. This way, the feature is entirely opt-in, and does nothing by default.

I do believe the -y/--yes flag should stay to temporarily disable this feature for places where interaction is undesirable (e.g. shell scripts or skill files).

[josephlou5]

I do believe the -y/--yes flag should stay to temporarily disable this feature for places where interaction is undesirable (e.g. shell scripts or skill files).

Do you have any objections to using --config git.confirm-on-push=never instead of --yes for one-off cases or scripts? Do you think the --yes flag specifically is worth adding to the command? I'm thinking that adding this flag would kind of mean we should also add a --no-confirm flag, so that users who have git.confirm-on-push = 'never' can also use a one-off flag to get interactive behavior. But then adding two flags to a command that already has a lot of options seems undesirable to me, especially since config overrides are already supported. Thoughts?

[slerpyyy]

Hmmm, I didn't think adding another flag would be a big deal, and the letter "Y" is rare enough at the start of words that -y is unlikely to collide with any future flag we might want to add, but I do see your point...

I'm removing the flag for now

[josephlou5]

I'm removing the flag for now

Will need to update the commit description too.