Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: keep the whole diff in diffedit's initial state? #5390

Open
v-gb opened this issue Jan 18, 2025 · 2 comments · May be fixed by #5393
Open

FR: keep the whole diff in diffedit's initial state? #5390

v-gb opened this issue Jan 18, 2025 · 2 comments · May be fixed by #5393

Comments

@v-gb
Copy link
Contributor

v-gb commented Jan 18, 2025

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

When I use jj diffedit, the first step is nearly always to select the whole diff, and then deselect what I want to drop, so I find the default behavior slightly annoying/backwards (I have accidentally blown away my working copy several times before due to this, but jj undo thankfully trivially fixes this, so not as important to me).

The "drop everything by default" behavior also doesn't seem to match the name of the command, or the help text of the command ("Touch up the content changes in a revision with a diff editor"). "edit" or "touch up" means to me that an empty change (jj diffedit + c) should do nothing, not drop the whole change. That'd be called "difffilter" or "diffselect" or something.

I actually just learned there is a keybinding to toggle everything :/.

Describe the solution you'd like

Start the diffedit ui with every box checked.

@martinvonz
Copy link
Member

I agree that we should do this. Just note that it varies from command to command. For jj split and jj squash -i, we probably want the current behavior. We will presumably want the to select all changes by default in the same cases in the 3-pane external diff editors.

@arxanas
Copy link
Contributor

arxanas commented Jan 18, 2025

For the built-in editor, it should just be a matter of changing the is_checked booleans in this file (but we would want to thread something through to make it configurable per command):

is_checked: false,

v-gb added a commit to v-gb/jj that referenced this issue Jan 18, 2025
(fixes jj-vcs#5390)

Currently, there is a blocker: when quitting the ui with 'q' after making no
changes, you get prompted with 'you have modified N files, are you sure?', which
seems like a bug in the scm_record library.
@v-gb v-gb linked a pull request Jan 18, 2025 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants