Hello, On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote: > As an example: to update to a new upstream release, I ideally just have > to drop the new upstream tarball, update d/changelog and am done. > Compare with [1] which is much more complicated, even ignoring the extra > complexity using dgit adds compared to just using git. > > [1] https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES As a package maintainer, if you don't keep the whole source package in git, you're giving up on a lot of the power of git. The most significant thing is that you cannot manipulate quilt patches as commits on a branch. It is also much more involved to cherry pick commits from upstream branches, and quickly obtain diffs between Debian's version of the code and arbitrary other branches, to mention a few other things. I also think that you're doing a disservice to downstream users. If you're trying to fix a bug in the packaged version of some software on your computer, you don't care about the distinction between Debian's packaging scripts and the upstream code. It's all going to be turned into a .deb once you've fixed your problem. You want the history of the whole thing. Thus, a git history that contains both the upstream git history and the Debian maintainer's changes to the packaging scripts is going to be very useful. A git history of only the Debian packaging scripts is much less useful. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature