Ask for confirmation before pushing to remote by slerpyyy · Pull Request #9969 · jj-vcs/jj

slerpyyy · 2026-08-11T12:26:44Z

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 · 2026-08-11T12:33:34Z

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 · 2026-08-11T14:06:11Z

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.

Pushing changes to a remote is one of the few operations that cannot be undone using `jj undo`, so extra attention is needed to make sure we use it correctly. Currently, the only way to see what `jj git push` will do ahead of time using the `--dry-run` flag, though using it with every push adds a lot of friction for the user. This change adds a config option `git.confirm-before-push` to prompt the user before changes are pushed to the remote. Implemented in #9969

PhilipMetzger · 2026-08-11T14:10:40Z

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 · 2026-08-11T15:57:37Z

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.

Pushing changes to a remote is one of the few operations that cannot be undone using `jj undo`, so extra attention is needed to make sure we use it correctly. Currently, the only way to see what `jj git push` will do ahead of time using the `--dry-run` flag, though using it with every push adds a lot of friction for the user. This change adds a config option `git.confirm-before-push` to prompt the user before changes are pushed to the remote. Implemented in #9969

Added in #9969

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).

PhilipMetzger · 2026-08-12T14:59:58Z

+    /// Automatically answer all prompts with "yes" and run non-interactively
+    #[arg(long, short)]
+    yes: bool,


nit: I don't think we should do it this way, if we're doing it at all

I do believe a flag like this should exist for the purpose of shell scripts, AI agents, or other places where interaction must be avoided without modifying the user configs. This particular flag is inspired by apt install, which has -y/--yes/--assume-yes. Do you have a different design in mind?

Do you have a different design in mind?

If this feature is opt-in only such a flag is unnecessary, as I said if we're doing it all it should be something which we slowly roll out.

PhilipMetzger · 2026-08-12T15:00:48Z

+    let needs_confirm = !args.dry_run
+        && !args.yes
+        && match tx.settings().get("git.confirm-before-push")? {
+            PushConfirmChoice::Always => true,
+            PushConfirmChoice::Never => false,
+            PushConfirmChoice::Auto => ref_updates.bookmarks.len() + ref_updates.tags.len() > 1,
+        };


nit: To make it a clean migration for our users, this initially should be opt-in and a warning should appear for the "old/current" behavior.

I mean you implemented a warning but please look at past migrations how we usually do that.

I don't think we need any warnings or hints. It's unlikely that the confirmation will be enabled by default. jj git push is the command to push changes, so why should it be interrupted by a confirmation prompt? The user can run --dry-run if needed.

@yuja This confirmation prompt is to catch mistakes, and getting a jj git push wrong is particularly annoying because it instantly updates an external remote, which you can't easily jj undo. The --dry-run flag is great when you're unsure what jj git push is going to do and you want to check manually, but you don't always know ahead of time when you're about to make a mistake. Always running the same command twice, once with and without the flag, is possible but it adds a lot more friction than pressing "y" on a prompt.

@PhilipMetzger I'm sorry, I'm not sure what you mean. I based the current implementation on the hint you get when you don't have a merge editor configured. What past migration do you have in mind?

You can add an alias to run jj git push --dry-run ...; <prompt>; jj git push ....

https://docs.jj-vcs.dev/latest/config/#aliases

Configurable push revset will also help if you occasionally get surprising results with the default revset.

#3650

ShiroKSH

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

Pushing changes to a remote is one of the few operations that cannot be undone using `jj undo`, so extra attention is needed to make sure we use it correctly. Currently, the only way to see what `jj git push` will do ahead of time using the `--dry-run` flag, though using it with every push adds a lot of friction for the user. This change adds a prompt to `jj git push` which, after listing the effects this push will have on the remote, asks the user to confirm before updating the remote. This interaction is controlled by the setting `git.confirm-before-push` (always/never/auto), and can be skipped using the `-y`/`--yes` flag. Implemented in #9969

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.

slerpyyy force-pushed the git-push-confirm branch 2 times, most recently from 1254654 to ea02ec6 Compare August 11, 2026 12:55

slerpyyy marked this pull request as ready for review August 11, 2026 12:55

slerpyyy requested a review from a team as a code owner August 11, 2026 12:55

slerpyyy force-pushed the git-push-confirm branch from ea02ec6 to 7c9d963 Compare August 11, 2026 14:06

josephlou5 reviewed Aug 11, 2026

View reviewed changes

Comment thread cli/src/config-schema.json Outdated

Comment thread docs/config.md Outdated

Comment thread CHANGELOG.md Outdated

slerpyyy force-pushed the git-push-confirm branch from 7c9d963 to e60cc49 Compare August 12, 2026 11:09

cli: git-push: Fix clippy::needless_late_init

91e21bb

Added in #9969

PhilipMetzger reviewed Aug 12, 2026

View reviewed changes

ShiroKSH requested changes Aug 12, 2026

View reviewed changes

Comment thread cli/src/commands/git/push.rs Outdated

Comment thread docs/config.md Outdated

slerpyyy force-pushed the git-push-confirm branch from e60cc49 to ade9d68 Compare August 12, 2026 22:06

josephlou5 reviewed Aug 12, 2026

View reviewed changes

Comment thread cli/src/commands/git/push.rs Outdated

Comment thread docs/config.md Outdated

Comment thread docs/config.md Outdated

slerpyyy force-pushed the git-push-confirm branch from ade9d68 to 358ec6f Compare August 13, 2026 09:19

slerpyyy requested a review from ShiroKSH August 13, 2026 09:29

ShiroKSH approved these changes Aug 13, 2026

View reviewed changes

Uh oh!

Conversation

slerpyyy commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

PhilipMetzger commented Aug 11, 2026

Uh oh!

slerpyyy commented Aug 11, 2026

Uh oh!

PhilipMetzger commented Aug 11, 2026

Uh oh!

joyously commented Aug 11, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

PhilipMetzger left a comment

Choose a reason for hiding this comment

Uh oh!

PhilipMetzger Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ShiroKSH left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ShiroKSH left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

slerpyyy commented Aug 11, 2026 •

edited

Loading

PhilipMetzger Aug 12, 2026 •

edited

Loading