Package: dgit
Version: 8.3
Severity: wishlist
See this mail from David Bremner. I think it should be possible to
have dgit run git-debcherry rather than its own quilt linarisatio.
This new mode would be useable with both split and unsplit view. I'm
not sure which should be the default.
Ian.
From: David Bremner <da...@tethera.net>
To: Ian Jackson <ijack...@chiark.greenend.org.uk>
Cc: debian-de...@lists.debian.org
Subject: Re: Survey: git packaging practices / repository format
Date: Wed, 29 May 2019 18:36:01 -0300
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Hi. Thanks for your contributions which I am trying to capture, but I
> don't think I fully understand them.
>
> David Bremner writes ("Re: Survey: git packaging practices / repository
format"):
>> With modified upstream files in the main branch, plus debian/*, but
>> usually no d/patches I use a seperate (manually
>> rebased) branch for patches, and export those at dsc creation time using
>> a gitpkg hook
>
> Is this the same setup as described by Simon McVittie for xorg
> packages (eg, mesa) ?
I don't think so. My own usage is "purer" and doesn't involve quilt;
the mention of d/patches is probably a red herring here; I only
mentioned because I remember that some users of git-debcherry like(d) to
commit exported patches to be compatible(ish) with gbp.
> If not I don't understand, because you say both that the upstream
> files are modified in your main branch, and that there are patches in
> d/patches but that is in a separate branch.
> Are the same changes
> represented twice, then, on two git branches ?
The patch branch (which is just a regular git branch), is just a linear
sequence of commits on upstream.
> You say "a gitpkg hook". Is the hook script in Debian or is it ad
> hoc ? My table would perhaps want to name it.
yes, it is /usr/share/gitpkg/hooks/quilt-patches-deb-export-hook (in
the package gitpkg).
>
>> With unmodified upstream files in the main branch, plus debian/*, but
>> usually no d/patches, I use git-debcherry to generate a quilt series at
>> dsc build time.
>
> I think I understand this one a bit better than the one above.[1]
> What constraints are there on the main branch, for this to work ?
>
There are no (known) constraints on the main branch, but the degree to
which it "works" varies. It guarantees the same working tree as you
started with, but not a one-to-one mapping between git commits and quilt
patches. In particular there can be a "debcherry-fixup-patch" containing
some changes that could not be nicely linearized into patches.
> [1] git-debcherry solves a very similar problem to dgit's quilt
> linearisation, which is used for example by dgit to construct `3.0
> (quilt)' patches out of the commits made by an NMUer.
Yes, that's why I pointed git-debcherry out to you when you started
designing dgit :P
> And I think git-debrebase branches are always suitable for use with
> git-debcherry, but git-debrebase knows how to make patches itself so
> you don't need git-debcherry then.)
Sure, except if you have a project already using git-debcherry, where I
guess git-debrebase might not work.
git-debcherry itself does not modify history, only generates source
packages. There is a companion script 'git-refresh' that I think
was never packaged (attached for reference). The idea is to bring
patches to the tip of history again, which I guess is a simplified
version of what git-debrebase does.
--
Ian Jackson <ijack...@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.
