On 8/18/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > The reason, I think, is that I suspect that the newly added file is a > binary file, no? Yes, that's correct. > That, in turn, will mean that the *patch* will have no > patch ID (or rather, it will have an empty patch ID) - which in turn will > make it invisible to "--ignore-if-in-upstream" if there are already some > *other* patches that also just adds a binary file (which I think there is: > I think upstream has "Add disk summarize tool (du.exe)" which I assume has > exactly the same patch fingerprint). The "du.exe" is only in the devel branch but there is five other patches that meets your criteria. > In other words, "git rebase" really is just a series of cherry-picks, but > it avoids patches that have the same patch ID as something that is already > upstream. That helps *enormously*, but it so happens that the patch ID's > don't work really well for binary diffs. Git cherry-pick seems to work on that particular patch: $ git cherry-pick b11cf4ce6262a7c3b243e3cfdc70e6b44682cb59 Finished one cherry-pick. Created commit 92a58d3: Added msmtp.exe SMTP client 1 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 bin/msmtp.exe > Try this patch - see if it helps. Totally untested! It will enable patch > ID's on binary diffs too, which should avoid this issue. That didn't help. Same symptom. //Torgil - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
