"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Johannes Thyssen Tishman <johannes@thyssentishman.com>
Subject:
Re: Weird behaviour when staging binary files interactively
To:
gameoftrees@openbsd.org
Date:
Wed, 30 Oct 2024 11:37:07 +0000

Download raw body.

Thread
And of course I forgot to attach the test.bin file. Apologies. Please
find it attached now.

2024-10-30T11:35:56+0000 Johannes Thyssen Tishman <johannes@thyssentishman.com>:
> 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
>