> 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". Doesn't `--text` already do that? Albeit with whitespace warnings. > So, no, I am less convinced "--binary" that forces "all paths are binary, so show binary patch" is a good idea. I'm not sure exactly what this means, but if one binary and one text file changed, then there should be a binary diff and a text diff, like there is currently. That's why I propose better binary file detection, instead of (what I understand to be) "make all patches in a patch file GIT binary patches, regardless if a file is text". But there is merit to that if you don't care about readability in a "fully binary patch", or you insist on not mixing text and binary in patches. The terminology is confusing because within a file produced by diffing two directories, there are multiple diff sections for each file diffed. So while the documentation says "output a binary diff", to be clearer it should say "output a binary diff only for binary files". On Tue, Jul 14, 2020 at 12:34 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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".
