summaryrefslogtreecommitdiff
path: root/absurd
Commit message (Collapse)AuthorAge
* absurd/git: Introduce log()Ian Jackson2016-12-19
| | | | | | | Right now this simply replaces all the echo >&2, producing no significant functional change. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
* absurd git-apply fallback: defend against debian/patches/series being an ↵Ian Jackson2016-10-25
| | | | | | unusual object, in case dpkg-source doesn't. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
* Import: Use absurd `git apply' emulation if gbp pq import failsIan Jackson2016-10-24
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 problems. 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'. Specifically: 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 <ijackson@chiark.greenend.org.uk>