Web lists-archives.com

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

Sean Whitton <spwhitton@xxxxxxxxxxxxxx> writes:

> 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.
> 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.

I can't speak for Ansgar, but “you don't keep the whole source package
in Git” is not implied by keeping Debian packaging separate. It's not
accurate to the workflow, at least as I described (I don't know Ansgar's
case, but nothing he described implies that either).

Rather, I keep the Debian packaging source separate from the upstream
source. That doesn't preclude Git access to the upstream source, and I
frequently use a Git repository cloned from upstream for that.

So, the Debian-packaging-in-a-separate-repository does not give up any
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.

The full power of Git is available when I manipulate upstream source to
refresh my Debian patches. Indeed, it's even neater to refresh those
patches by going straight from the only-upstream-source repository.

> 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.

Conversely, I think it does a disservice to downstream users to mix in
Debian packaging changes with upstream changes. The separation is useful
and much easier to maintain when the repositories are separate.

 \         “Time is the great legalizer, even in the field of morals.” |
  `\                                                 —Henry L. Mencken |
_o__)                                                                  |
Ben Finney