As a workaround, I deleted the offending logic from debian/rules. However, I would prefer to keep the diff from Ubuntu's debian/ directory to my debian/ directory as small as possible.
Some other workarounds I haven't tried:
* Duplicate the patches to another subdirectory inside debian/ and adjust paths in debian/rules. That would require manual intervention whenever the set of patches changes.
* Add a pristine-tar branch or upstream/<version> tag with the contents of an arbitrary snapshot. The *.debian.tar.gz part of the source package would continue to grow unless I periodically refreshed the pristine-tar branch or upstream tag. The build might break if upstream deletes or renames a file because the *.debian.tar.gz cannot encode file deletions (except in patches). Also, the upstream portion of the package version would have to be fixed to something like `29~git`, otherwise git-build-recipe would be unable to find the upstream sources. (I think that's OK, but I'm not certain.)
The reason I want this is to make it easier to automatically produce Emacs snapshots. The current debian packaging for Emacs parses debian/ patches/ *.patch to build a README: <https:/ /git.launchpad. net/ubuntu/ +source/ emacs/tree/ debian/ rules?h= import/ 1%2528. 2%2b1-15ubuntu1 #n253>. The quilt-to-native conversion done by git-build-recipe breaks that logic.
As a workaround, I deleted the offending logic from debian/rules. However, I would prefer to keep the diff from Ubuntu's debian/ directory to my debian/ directory as small as possible.
Some other workarounds I haven't tried:
* Duplicate the patches to another subdirectory inside debian/ and adjust paths in debian/rules. That would require manual intervention whenever the set of patches changes.
* Add a pristine-tar branch or upstream/<version> tag with the contents of an arbitrary snapshot. The *.debian.tar.gz part of the source package would continue to grow unless I periodically refreshed the pristine-tar branch or upstream tag. The build might break if upstream deletes or renames a file because the *.debian.tar.gz cannot encode file deletions (except in patches). Also, the upstream portion of the package version would have to be fixed to something like `29~git`, otherwise git-build-recipe would be unable to find the upstream sources. (I think that's OK, but I'm not certain.)