Skip to content

merge-tools: builtin: handle conflict file as binary to disable hunk selector #6337

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

yuja
Copy link
Contributor

@yuja yuja commented Apr 14, 2025

Closes #4963

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 tests to cover my changes

yuja added 2 commits April 14, 2025 23:30
I'm going to add FileContents::Conflict, and the number of combinations would
explode.
…selector

Previously, a conflict file was materialized, and the edited content was written
as a normal file. I don't think we can naturally support selecting conflict
hunks with the current scm_record data model and UI, so this patch turns off the
hunk-level selector.

Closes jj-vcs#4963
@yuja yuja requested a review from a team as a code owner April 14, 2025 14:43
Copy link
Member

@martinvonz martinvonz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that you can no longer resolve conflicts and use then diff editor to squash them into an ancestor (without squashing unrelated changes in the same file)? I have sometimes taken advantage of that working. I don't know if others have.

@yuja
Copy link
Contributor Author

yuja commented Apr 16, 2025

Does this mean that you can no longer resolve conflicts and use then diff editor to squash them into an ancestor (without squashing unrelated changes in the same file)?

Oh, does that work because all resolved hunks are selected? (If some were unselected, the edited content would have materialized conflict as non-conflict text.)

It might be better to parse the edited content back to conflict, then. This wouldn't always work, but should be better than the current state.

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 this pull request may close these issues.

jj diffedit doesn't allow restoring conflicts
2 participants