Re: Survey: git packaging practices / repository format

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Jun 21, 2019 at 05:59:52PM +0100, Ian Jackson wrote:
> > There's a variant of this which is to grab updates from upstream using
> > "git cherry-pick -x COMMIT_ID ; git format-patch -o debian/patches -1 COMMIT_ID".
> > 
> > At the moment I'm updating debian/patches/series by hand, but I really
> > should automate all of the above.
> 
> Thanks for the reply.  I think this approach is novel to me.
> 
> I think in my third column there, "Tools for manipulating delta from
> upstream, building .dsc, etc.", "git merge" is not entirely right to
> describe this approach, and certainly `1.0-with-diff' is wrong.
> 
> How do you update to a new upstream version while preserving your
> delta queue ?  Just git merge with an upstream seems like it might
> work sometimes but at some point the patches will need to be
> refreshed...

Well, I'm cheating a bit, since I *am* upstream for the package in
question.  In that case, or in the case of people who can follow an
"upstream first" policy, when you sync up with upstream, by definition
you can just completely empty debian/patches.

I do something similar with my ext4 kernel patch queue; when I sync
with upstream, I know which patches haven't been sent upstream ---
they are at the end of the patch queue in what I term the "unstable
portion" of the patch queue, so it's easy enough to preserve then when
I rebase from 5.1-rc2 to 5.2-rc2; and most of the time either no patch
updating is necessary, or when there is, I just fix up the patches and
commit them as part of the rebase commit where I delete the patches in
the "stable portion" of the patch queue, which are upstream, and the
update the series files so it looks something like:

# v5.2-rc2    <---------- this is the "origin" of the ext4.git tree

####################################################
# unstable patches
####################################################

unstable-patch-1
unstable-patch-2

				- Ted