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.
git-refresh
Description: Binary data
