Sergey Matyukevich <sergey.matyukevich.os@xxxxxxxxxxxxx> writes: > Hello Kalle, > >> Failed to apply: >> >> fatal: sha1 information is lacking or useless >> (drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c). >> error: could not build fake ancestor >> Applying: qtnfmac: modify full Tx queue recovery >> Patch failed at 0001 qtnfmac: modify full Tx queue recovery >> The copy of the patch that failed is found in: .git/rebase-apply/patch >> >> 5 patches set to Changes Requested. >> >> 10007281 [1/5] qtnfmac: modify full Tx queue error reporting >> 10007279 [2/5] qtnfmac: enable registration of more mgmt frames >> 10007283 [3/5] qtnfmac: drop nonexistent function declaration >> 10007285 [4/5] qtnfmac: modify full Tx queue recovery >> 10007287 [5/5] qtnfmac: advertise support of inactivity timeout > > My assumption is that by default all the patches should cleanly apply > to wireless-drivers-next. I could apply the patch in question to > wireless-drivers-next without any issues. Odd. How did you apply it? My script uses 'git am -s -3' individually for each patch in the series, but to my knowledge that shouldn't cause any problems. > Rebase of the whole series on top of wireless-drivers-next looks good > as well. I will resend rebased patches as v2. Thanks, sending v2 is the easiest for me. If there are problems again I'll investigate in detail what's going on. > Meanwhile do you have any idea what could go wrong ? The error message > looks scary... You mean the "sha1 information is lacking", right? It means that git was not able to find a common ancestor for the file which it could use to create the 3-way merge. Usually that happens when people have out-of-tree patches on the branch they are submitting from. And that's why I recommend to use the w-d-next master branch as the baseline when submitting patches, and not have any other custom patches applied on the branch. This should keep sha1 information correct and make it possible for git to use 3-way merge. -- Kalle Valo
