Package: dgit Version: 3.10 Severity: wishlist Dear Maintainer,
this is a feature request. I am not sure if the bugtracker is the right place for this; if not -- or if the feature totally doesn't fit your vision of dgit -- then feel free to close. I just felt like I had to raise this idea. My main use-case for dgit right now is using it as a tool for some sort of "patch overlay". From-source distros like Gentoo typically have a workflow for applying some patches to things before they are built; this is of course more complex is binary distros like Debian. Still, dgit goes a long way: I can "dgit clone" anything, then I can just patch the source in-tree. I don't have to learn quilt or merge all my patches into one or whatever the Debian source format says, I just use plain git. Ideally, I'd then just do "dgit sbuild" (well, plus some flags) and get a nice clean build of the package with my patch. When the package is updated in Debian, I do "dgit fetch" followed by a rebase -- standard git workflow. The trouble is, this only *almost* works. The one thing that doesn't work is about version numbers. I have to add a new changelog entry so that my version has a different version number than Debian's (usually I append `+local` to the current Debian version). This changelog entry has to be committed to git, and that commit has to be manually updated after each rebase. This is needlessly tedious and error-prone. So, what about dgit supporting a flag to compile the package at some version number other than the one given in the changelog? Maybe I could run "dgit --version-add-suffix=+local sbuild", and it would do the "add +local to version number" automatically for me? That would be great. This could be implemented e.g. by dgit synthesizing a changelog entry with the given version number. Ideally these would not accumulate over time. (Even more ideally, this wouldn't even ever show up in the git history; however, considering that the quilt-fixup patches do show up, that sounds unrealistic.) Or maybe (likely?) there is some much better way to better support this kind of workflow that I can't imagine because I don't know all the tools well enough. :) Anyway, thanks for making dgit, and thanks for considering this request. Kind regards, Ralf -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0+ (SMP w/8 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages dgit depends on: ii apt 1.4.6 ii ca-certificates 20161130+nmu1 ii coreutils 8.26-3 ii curl 7.52.1-5 ii devscripts 2.17.6 ii dpkg-dev 1.18.24 ii dput 0.12.1 ii git [git-core] 1:2.11.0-4 ii git-buildpackage 0.8.12.2 ii libdpkg-perl 1.18.24 ii libjson-perl 2.90-1 ii liblist-moreutils-perl 0.416-1+b1 ii libperl5.24 [libdigest-sha-perl] 5.24.1-3 ii libtext-glob-perl 0.10-1 ii libtext-iconv-perl 1.7-5+b4 ii libwww-perl 6.15-1 ii perl 5.24.1-3 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:7.5p1-5 Versions of packages dgit suggests: ii sbuild 0.73.0-4 -- no debconf information
