cutting /splitting a commit with only binary changes left in one commit failes

[elonderin]

use case: i had a commit with a couple of binary files but accidentally a change in a source file that i wanted to move to it's own commit

so i fired up git revise -c my-hash

...
Apply this hunk to index [y,n,q,a,d,e,?]? n

invalid value: cut part [1] is empty - aborting

it appears that the cut operation doesnt consider binary changes....

[mystor]

The cut operation internally runs git reset --patch, which works on the git add --interactive engine under patch mode. https://git-scm.com/docs/git-add#_interactive_mode

I'm guessing the interactive backend doesn't currently handle binary files. I'd prefer not to re-implement the interactive hunk selector, as it's a decent amount of complexity. I'm guessing the easiest approach would be to enumerate changed files, and prompt for ones which I "think" are binary after running the hunk selector.

In this case you can probably build your split by splitting in reverse (saying y to the question), and then doing a git revise -i to flip the order of the commits in a second pass.

[mystor]

(I should clarify - due to the current implementation, binary changes will always end up in the second commit of the split.)

[elonderin]

(I should clarify - due to the current implementation, binary changes will always end up in the second commit of the split.)

ah, good to know. since i'm a new user i haven't noticed that yet. good enough workaround for me then.

feel free to close the issue.