Re: Git Packaging: Native source formats
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.
I can't speak for git-dpm, but with git-debrebase and 1.0 native
source format, there would not any patch files.
> Extracting specific changes by comparing only two Git branches with a
> complex merge history is certainly possible to do with native Git tools,
> but I would classify it as an advanced Git skill. I think there are a lot
> of upstreams using Git for whom that operation would still be quite
> challenging.
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 is one of those cases where knowing your upstream is invaluable.
I certainly agree with this. I don't think anyone is saying that
using (say) a merging git workflow with a native source package format
should be universal, or even the default.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: