Web lists-archives.com

Re: Preferred git branch structure when upstream moves from tarballs to git




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