corruption of staged/commited changes

[calestyo]

Hey Andrew.

I found a case where I think crecord causes corruption (of the merged data), unfortunately I couldn't find a simple reproducer, so I'll mail you my test files (which I rather don't want to be public) afterwards [edit: done] (@debian.org).

There will be a file.v1 which is the "orginal" state and committed to the repo. And file.v2, which contains multiple modifications, of which some will staged via crecord.

Here's how to reproduce the issue with them:

git init test
mv ../file.v1 file
git add file
git commit file -m foo
mv -f ../file.v2 file

If you look now at the changes with e.g. git difftool -d, you'll see 2 hunks:

1. there's one hunk in the "middle", which
   • changes two comment lines and adds a bunch of other non-empty lines right after them
   • there's no changes in empty / whitespace-only lines
2. there's another hunk nearly in the end, which:
   • adds 4 empty lines after the last function, then another block of code, and then there's again 16 empty lines and copyright comment (which were already there).
   • so old code,… 4 new empty lines,… a new block of code… 16 old empty lines and some comments

Now:

git crecord

and within that:

• unselect everything
• from the 1st hunk, select only the 2 removed and 1 added comment lines (the first three shown lines one can select), but don't select anything else
• from the 2nd hunk select everything

You already should see that the 2nd hunk looks odd, it starts right with the new block of code (no leading 4 newlines) and ends with 4 empty newlines (which could of course just be from the positioning of the hunk.

But when now staging and yes... and then git difftool -d --staged, you'll see 2 hunks:

• the changed comment lines,... which are good
• but the 2nd hunk is broken, it's now:
  • old code
  • 13 empty lines
  • the new block of code
  • only 7 remaining ones of the previously 16 empty lines
  • the comments

When you now commit the staged changes (i.e. no further adds of the not yet staged changes + git commit -m bar)... and then git reset --hard the remaining (not yet staged changes, which should only be the non-comment lines from the middle hunk), you see that the end of the actually committed file is messed up, and now as it was before.

I presume there's something wrong with the placement of the hunk.

Cheers, Chris.