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: jj resolve should recommend jj chmod when hitting an executable bit conflict #2420

Closed
glencbz opened this issue Oct 24, 2023 · 2 comments

Comments

@glencbz
Copy link
Contributor

glencbz commented Oct 24, 2023

Currently, jj resolve outputs something like:

Error: Failed to resolve conflicts: Only conflicts that involve normal files (not symlinks, not executable, etc.) are supported. Conflict summary for "foobar":
Conflict:
  Removing executable file with id e80f6f12e211b26ea895ee714a42792fc2629c9a
  Adding executable file with id 4aeaee0c9c39937dc96e3f67f3c597a9803938ef
  Adding executable file with id 2e8e7acb76c93096f23358d06d0b9fb9c6124c22

Which hints that the solution has to do with the executable bit, but not how to change it in a way that jj can understand. The first tool users will probably reach for is chmod, but that doesn't work (because it doesn't touch the mtime..?), making this problem extra-frustrating.

The correct answer is to jj chmod the file, but the discoverability feels low. We should call out jj chmod, and ideally, give the appropriate <mode> argument that makes jj.

@martinvonz
Copy link
Member

Makes sense. There's also #1279 about not even considering most cases conflicts. In your case above, for example, the result should be an executable file (it was executable before and it was still executable afterwards on both sides of the conflict).

@ilyagr
Copy link
Contributor

ilyagr commented Oct 24, 2023

This should be superseded by the fix to #1279. 🎉

Feel free to reopen if I missed something.

@ilyagr ilyagr closed this as completed Oct 24, 2023
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

3 participants