Generated patches lose binary file changes
TortoiseHg can generate patch files. One way to do that is to right-click on a revision, then Export, then Export patch.
Unfortunately, by default, if the changeset modifies (or removes) a binary file, the patch is incomplete, as it just contains a line saying that the file changed, but not the change itself.
#!diff
diff -r rev1 -r rev2 some/file.png
Binary file some/file.png has changed
This occurs because TortoiseHg calls Mercurial via the CLI and uses default options. Mercurial provides the --git
option to specify binary changes, but it is not enabled by default:
#!diff
diff --git a/some/file.png b/some/file.png
index rev1..rev2
GIT binary patch
literal 111
zc$@*U...
Whether --git
is enabled depends on the "git format" setting (in the Diff tab), which is by default "Unspecified" (relying on Mercurial's default).
While this behavior is well documented for the hg
command, this is less the case for TortoiseHg, which does cover this in section 7.2. Pitfalls of its manual:
The standard patch format cannot describe binary files, renames, copies, or permission changes. If your patch needs to record any of those things, you will need to enable git patches via:
[diff] git=True
Mercurial 1.5 improves its behavior in this regard. It will warn you when git diffs are required, or sometimes upgrade to the git format automatically. See also the diff section of the hgrc documentation.
While the last quoted paragraph seems to indicate this would be solved, this is unfortunately not the case as of TortoiseHg 6.4.2. It can happen that we don't realize that there are indeed binary files, and we end up having patches lying around that "won't work" when needed.
TortoiseHg should at least warn when it generates an imprecise patch due to a modification to a binary file, ideally offering to generate an exact patch.
I recommend to consider also changing the default behavior so that binary changes are specified. Reportedly, both hg and TortoiseHg would be happy to import Git extended diff files.
Credits to Fernando Nájera, who reported this in a ticket on which this one is heavily based, but which somehow got lost