I bumped into a few weird behaviours when staging modified binary files
interactively. Here is my best effort to summarize them. All commands
below build upon each other (i.e. the last command in this email depends
on all previously executed commands).

For consistency with the examples below, I've attached the same binary
file I used (test.bin). The file was created with the following command:

dd if=/dev/urandom of=test.bin bs=1024 count=5

1. Trying to stage a hunk of a binary file that's been modified (e.g.
when blindly running 'got stage -p' on the whole worktree) results in
got trying to show the actual hunk diff:

mkdir src
cp test.bin src
got init repo.git
got import -r repo.git -m 'test' src
got checkout repo.git
cd repo
sed -i -e '5s/./x/' -e '10s/./y/' -e '15s/./z/' test.bin
got stage -p test.bin

Instead, got should probably treat all changes to the binary file as a
single hunk and show a message similar to the one from got diff: Binary
files test.bin and test.bin differ.

2. Staging all hunks of the binary file by pressing 'y' on all prompts
(i.e. staging the whole file) causes the status

got status
MM test.bin

when it should be

got status
 M test.bin

since the whole file has been staged.

3. When committing the staged binary file, the file still appears as
modified and the diffstats printed with 'got log' show incorrect
information:

got commit -m 'test 1'
got status
M  test.bin
got revert test.bin
R  test.bin
got log -d
-----------------------------------------------
commit d9381ec290cce257f0ceaedd5797294674d8b540 (main)
from: Johannes Thyssen Tishman <johannes@thyssentishman.com>
date: Wed Oct 30 11:09:14 2024 UTC
 
 test 1
 

0 file changed, 0 insertions(+), 0 deletions(-)

-----------------------------------------------
commit fdbadc1e633b808a03a374e6f7d7fd9e14e42a6b
from: Johannes Thyssen Tishman <johannes@thyssentishman.com>
date: Wed Oct 30 11:01:21 2024 UTC
 
 test
 
 A  test.bin  |  0+  0-

1 file changed, 0 insertions(+), 0 deletions(-)

It seems as if an empty commit was made (note the "0 file changed").

4. Drop operations with 'got histedit' on commits after these "empty
commits" cause the "empty commits" to be dropped as well:

echo 'blah' > file_1
got add file_1
got stage file_1
got commit -m 'test 2'
got up -c :head:-2
got he
# drop 'test 2' commit
d9381ec290cc -> no-op change: test 1
076e5da181a0 ->  drop commit: test 2
Switching work tree to refs/heads/main

I assume this is correct behaviour as it is labeled as no-op, but I
thought I mention it just in case.

got -V
got 0.105-current