Re: Preferred git branch structure when upstream moves from tarballs to git
- To: debian-devel@lists.debian.org
- Subject: Re: Preferred git branch structure when upstream moves from tarballs to git
- From: Ben Finney <bignose@debian.org>
- Date: Thu, 02 May 2019 15:11:27 +1000
- Message-id: <[🔎] 86muk5v3sw.fsf@benfinney.id.au>
- References: <878svtcgp3.fsf@moose> <86y33suwxu.fsf@benfinney.id.au> <CAKTje6GROWV0gpBNEgY8ephwD0fhrAvtYC3NwOXAnkwtF7N8Aw@mail.gmail.com> <1556588889.5889.9.camel@stuart.id.au> <877ebcc9k9.fsf@43-1.org> <87muk76qv7.fsf@iris.silentflame.com>
Sean Whitton <spwhitton@spwhitton.name> 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
Reply to: