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: Improve conflict resolving for binary files #3540

Open
ChristianG1984 opened this issue Apr 19, 2024 · 6 comments
Open

FR: Improve conflict resolving for binary files #3540

ChristianG1984 opened this issue Apr 19, 2024 · 6 comments

Comments

@ChristianG1984
Copy link

Is your feature request related to a problem? Please describe.
The problem is related to that Issue #2757.
For example:
You have a project with images (*.jpg, *.png, etc.) or other native file formats, which are generated by your tool of choice. (*.blend project files from Blender, any Office documents, etc.)
Currently, when you have to resolve a conflict of such binary file, it's impossible to do it right now, because the conflicted binary files getting merged together into one "blob" of unusable data.

Describe the solution you'd like
The solution to that problem would be quite simple. (At least from the usability point of view. Maybe not on the implementation side to be honest. 😉)
When the user wants to resolve a given conflict with a binary file, jj could put both files side by side into the current workspace folder.
For example:
You have a file flower.jpg.
Then you have two different changesets: aaaa and bbbb. (These are the random identifiers, which jj generates on every jj new.)
In both changesets, flower.jpg changed, of course.
Then, if you want to merge these changesets (or rebase one onto the other), jj could simply place both files side by side with filenames like flower.aaaa.jpg and flower.bbbb.jpg.

This would make the conflict resolving process for binary files really easy for the user.

Describe alternatives you've considered
The current work around for that problem is this (to stay on my example above):
I do a jj new aaaa and rename the file flower.jpg to flower.aaaa.jpg. (That new changeset based on aaaa may be named cccc for that example.)
Then I switch to the other changeset bbbb with jj new bbbb and do a jj squash --from cccc.
Then, I have the two files in one place side by side: flower.jpg and flower.aaaa.jpg. Then I can simply decide, which file to keep. In that example, I would delete flower.jpg and rename flower.aaaa.jpg to flower.jpg.

Additional context
There is no additional context.

@martinvonz
Copy link
Owner

Have you tried jj resolve with a graphical merge tool? I would think that many of them are able to display images and help you pick one side.

@necauqua
Copy link
Collaborator

it's impossible to do it right now [..] The current work around for that problem is

I think a better way to do this currently is jj restore --from one-of-the-parents path/to/file.bin

Although yeah it's if you know which version you want to keep, doesn't give you a way to compare and choose

@ChristianG1984
Copy link
Author

Thank you both for the fast response!

@martinvonz I can try that out. I just had the "meld" tool at hand, but it seems, it can only handle text files. (I'm a Windows user, by the way. 😉)
I will try to configure the WinMerge-Tool for jj and test out, how that works.

To be honest: It's not so, that I have often to deal with binary files within Version Control Systems. (Up to 99%, I have to work with plain source code and text files within Version Control Systems. 😅)
But I found jj and right from the beginning, I loved this VCS! And so I like to play around with it to test, where it's strengths and weaknesses are. And I was curious about, how it will handle such tough cases with conflicts in binary files.
So, at the moment, without any supported external tool, you have almost no chance to properly handle any conflicts with binary files.

@necauqua Thank you for this hint! That is really the better workaround for that issue. I will remember that.

@ilyagr
Copy link
Collaborator

ilyagr commented Apr 20, 2024

Have you tried jj resolve with a graphical merge tool?

I will try to configure the WinMerge-Tool for jj and test out, how that works.

One tool that worked pretty well for me was any IntelliJ IDE (e.g. PyCharm Community Edition). IntelliJ has plugins to compare images in the diff, possibly other types of files.

There is also https://www.scootersoftware.com/beta. They have a generous free trial, and image support, but it's a bit hit or miss (the image comparison was very slow for me and for other types of files).

@ChristianG1984
Copy link
Author

@ilyagr Thank you also very much for that recommendations! (Well, in the open source space, there are really not that many good diff/merge tools, which can simply handle all kind of files.)

I tried it with WinMerge and it worked as expected.

Here is the configuration for the jj config.toml file:

[merge-tools]
winmerge.program = "winmergeu"
winmerge.edit-args = ["/e", "/s", "/u", "$left", "$right"]
winmerge.merge-args = ["/e", "/s", "/u", "$left", "$base", "$right", "/o", "$output"]

Of course, the directory of WinMergeU.exe has to be added to the PATH Environment variable before.

Just as a side note or recommendation for other WinMerge Users:
WinMerge is a bit confusing, if you want to solve a conflict of two (or three) images. Do not try to fiddle around with "copy differences/changes to the left/right/middle" or the like. (I have no idea, what WinMerge is really doing then with the images.)
Just decide, which version of the image you want to keep. (The "left", "middle/base" or "right")
Then go to File -> Save as ... -> Left/Middle/Right save as ... and in the opening dialog, select the output_[...] file, which was created from jj before and accept to overwrite that file.
Then close the WinMerge-Window and the conflict is marked as resolved. 😊

@ilyagr
Copy link
Collaborator

ilyagr commented Apr 20, 2024

Well, in the open source space, there are really not that many good diff/merge tools, which can simply handle all kind of files

Technically, the community editions of IntelliJ tools are open source. I'm not sure how easy they are to use if you get them from the GitHub repo, though.

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

No branches or pull requests

4 participants