On Thu, Feb 9, 2017 at 5:35 AM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: >> Strange. That is the only patch I found in my series. > > Well, it was the rigth patch in the sense that it had the right > log message and stuff but the resulting diff was only correct > within a 1 line context. With a 3 lines context 'git am' or > a pure 'patch < ...' should have given a conflict as one of > the patch that was initialy just after it > (1856b3461 "fix killing OP_CAST & friends") made also some > changes in the same lines and these two patch have now been > exchanged. I see. So what happen is that the git am rejects it while the patch program has not problem apply the patch. So I take the patched version, which was wrong in terms of conflict resolution. I go through my logs, similar things happen in the following two commit. 684710647 testsuite: check patterns presence or absence in output 49118f27e2 testsuite: check the nbr of times a pattern should be present "git am" initial rejects it but the patch program accepts it. Can you double check this two changes sounds correct to you? I did take a second look, seems normal to me. Any way, your new version of patch is applied in sparse-next. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
