gbp import can fail due to git apply not understanding patches.
This is #841867 (against dgit).
The underlying problem is #841866 (in gbp pq) which exposes things
like #841865 and #829067 (in git). I imagine there are other lurking
incompatibilities between git-apply and dpkg-source.
We could in principle reimplement the gbp patch metadata extraction.
But that would be quite tiresome and have its own compatibility
The real problem is just `git apply'. (Indeed gbp already tries git
apply without, and then with, a whitespace fix option.) We work
around the trouble by providing our own implementation of `git apply'.
We try to do things the sane way (just running gbp pq import) first.
If that works, great. If it doesn't, we put /usr/share/dgit/absurd on
the PATH. That contains only a sh script called `git'. This sh
script figures out whether the caller is trying to invoke `git apply'.
If not, it runs the real git.
If the caller wanted git-apply, the absurd git script emulates it
using dpkg-source --before-build. Conveniently, we know that the
series file will not be touched by patches. So we can write just the
patch we care about into the series file, and run --before-build,
which applies just that one patch.
The results are committed (minus the .pc), and for the next patch,
dpkg-source sees again a tree with simply a single patch to apply.
We try ordinary gbp pq first because our absurd approach is very slow
on a big tree. Also we would like to maximise our chances of the
import working. If git and/or gbp ever work better by themselves, all
of this craziness will simply not happen.
Signed-off-by: Ian Jackson <email@example.com>