Fix incorrect salt when partially staged files are commited

[Aramgutang]

See ticket #118.

[jmurty]

@Aramgutang Can you think of any way we could add unit test coverage for partial commits of encrypted files?

Since git-p refuses to work with transcrypt-encrypted files it might be tough to simulate the behaviour.

[Aramgutang]

Yeah, I read through the git add/apply/am documentation, and couldn't find anything useable. Basically the scenario to reproduce requires invoking the clean filter for a file, while feeding it input that isn't actually the contents of the file, all within the context of generating a blob object for the change.

The various GUIs probably have their own implementations of this, which is why some seem to be able to handle staging partial changes on encrypted files, and some aren't.

[Aramgutang]

I read through the code for git-cola, and it appears that the way it stages hunks/lines is by generating patch files, writing them to a tmpfile, and passing them to git apply:

https://github.com/git-cola/git-cola/blob/b65aced9c089183eb008cd8c276b3c1941ee1f87/cola/diffparse.py#L261 https://github.com/git-cola/git-cola/blob/ac7e533541b46f7de5e778132be11227639ba0a7/cola/cmds.py#L287

But then again, staging partial changes to encrypted files in git-cola doesn't actually work, and it's probably because git apply doesn't pass the content through the filters, and neither does git-cola before writing the patchfile (which was the code I was hoping to find).

I reckon the only viable way to approach it would be along the lines of:

• Commit encrypted file.txt with content "AA"
• Save its encrypted content for reference later
• Modify file.txt to contain "BB"
• Call the clean filter script directly, passing "BA" into its stdin, and "file.txt" as the filename argument
• Generate a patch file using the received output and the encrypted content of the committed version we saved from before
• git apply the patch to the index, but not the working tree (using --cached)
• Modify file.txt to contain "BA"
• Verify that git status lists file.txt as having unstaged changes (prefix MM when run with -s), but git diff outputs nothing
• With the fix in place, git status should not list file.txt as having unstaged changes (prefix M), and the diff should still be empty

Seems like a lot of work...

[jmurty]

Whew, yeah, definitely a lot of work. For this one, knowing that the change hasn’t broken anything already tested (most features) is probably good enough.

Thanks for the explanation @Aramgutang

[jmurty]

Thanks for this fix @Aramgutang!

I tested it manually with VSCode pre- and post-fix and found the behaviour exactly as you described.

It's weird that VSCode allows partial commits when other tools refuse to, but that's a pretty important Git "client" to work with.