On Friday, August 30, 2019 12:05:45 PM EDT Russ Allbery wrote:
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > Russ Allbery writes ("Re: Git Packaging: Native source formats"):
> >> [ discussion of benefits of maintaining the Debian delta as
> >>
> >> a linear series of broken-down changes ]
> >>
> >> There are obviously ways to represent this with a pure Git repository,
> >> but
> >> apart from using a patch system on top of 3.0 (native), at which point I
> >> don't understand why one wouldn't just use 3.0 (quilt), they require
> >> multiple branches and thus aren't available directly in the archive.
> >
> > This is not true. There are at least two ways of doing this without
> > using a patch system: git-debrebase and git-dpm.
> >
> > Both of these use only a single primary git branch which contains both
> > upstream history, and Debian changes to upstream files represented as
> > git commits.
>
> It's a fair point that I didn't account for a rebase workflow in my
> analysis, and that's definitely an alternative.
>
> However, while analyzing a rebased branch isn't as hard for other people
> as a branch with a complex merge history, it does mean that upstream has
> to find a way to extract patches to their code from a branch that also has
> packaging-only changes and their upstream changes, and this is non-trivial
> for a lot of people. It's certainly way harder than just pointing them at
> a directory full of patches.
>
> > This is also not that hard, in simple cases. There is a tool
> > git-debcherry which can do it automatically. I haven't used it but AIUI
> > if your Debian delta queue has few commits, and doesn't have commits
> > which involve merge conflicts with upstream merges (basically, if each
> > change is carried Debian only for a short time), it will always produce
> > the nice output you would hope for.
>
> This lets you generate the patches for people on demand, but they aren't
> just sitting out there for anyone to look at whenever they want.
>
> I suppose it could be provided as an automated service that publishes the
> results, but that would be a piece of infrastructure someone has to run.
>
> Anyway, this is probably only applicable to a minority of upstreams and
> packages, and more upstreams these days would just like all patches as
> PRs.
It's not particularly rare for me to poke through other distros package
patches when I'm trying to figure out how to solve a problem. I suspect I'm
not the only one. I think having explicit patches available is a really good
thing for cross-distro collaboration (in addition to upstream collaboration).
Scott K
