Jason Xu <jasonx98@xxxxxxxxx> writes: >> The description for the --binary option reads as follows: >> >> In addition to --full-index, output a binary diff that can be applied >> with git-apply. Implies --patch. >> >> So we need to fix either the documentation or the code. >> >> I looked into what it takes to fix the code to do this; it's fairly >> straightforward, but it does cause some testsuite failures which assume >> the current behavior and will likely involve a small series. So if >> other folks agree, I'm happy to pick this up in the next couple of weeks >> and add support for it that would hopefully hit Git 2.29. I am not convinced. The "--binary" option was invented as a way to tell Git to produce something that can be applied, where Git stopped at saying "binary files differ". So a commit that touches two paths, one text and the other binary, used to produce a textual patch for one and a useless "binary files differ" for the other in "git show". Such a commit can be made more useful with "git show --binary" to tell the former to still produce textual and readable patch while showing the xdelta based "binary patch" Git invented. So, no, I am less convinced "--binary" that forces "all paths are binary, so show binary patch" is a good idea. And viewed with the knowledge of that history, >> In addition to --full-index, output a binary diff that can be applied >> with git-apply. Implies --patch. this description is correct---the choice is not between "showing a binary diff and showing a useless textual diff"; the choice is between showing "binary files differ" and appliable "binary patch".