On Mon, Jan 02, 2017 at 01:09:35PM -0800, Nikolaus Rath wrote: > On Jan 02 2017, Russ Allbery <r...@debian.org> wrote: > > Furthermore, it forces a rebased, clean representation of the patches, > > which I for one hugely prefer to the mess that you get if someone was > > packaging in Git and just randomly commits things directly to the > > packaging branch intermixed with merges from upstream. A few releases > > done that way will leave you almost completely unable to extract a rebased > > patch set against the current upstream source. (I have made this mistake > > so many times with my own packages.) > > Have you tried to use git-debcherry in those situations? I have tried it > in some simpler cases and worked very well, but I'd be curious if anyone > has tried it on larger and more complex repositories.
I've found git-debcherry to work well when cherry-picking patches _from_ upstream or upstream is receptive to merging patches. If patches live in the Debian package for quite some time (either intentionally as Debian-specific changes or because it takes time to get upstream) then you lose IMO relevant metadata in the debcherry-exported patches. I ended up switching to gbp pq for the one package where I have long-lived patches. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB