Re: Git Packaging: Native source formats
Ian Jackson <ijackson@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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: