Bug#828775: Support multiple patch queues branches

[Guido Günther]

On Mon, Jun 27, 2016 at 08:41:18PM +0200, Michael Biebl wrote:
> Package: git-buildpackage
> Version: 0.7.5
> Severity: wishlist
> 
> Hi Guido,
> 
> as discussed offline, in pkg-systemd we typically have two type of
> patches: upstream cherrry-picks and Debian specific patches. Upstream
> cherry-picks happen much more often and should ideally be applied
> directly on upstream master (to avoid merge conflicts), i.e. before the
> Debian patches.
> 
> With the current gbp pq approach, the workflow atm looks like:
> gbp pq import --force
> git cherry-pick <commitid>
>   which means the new cherry-pick is the last patch in
>   debian/patches/series
> git rebase -i
>   to reorder the new cherry-picked patch
> 
> Ideally we would have two patch queue branches: one for upstream
> cherry-picks and one for Debian specific patches.

In case of the  upstream cherry-picks the branch should be based on the
upstream branch and not the Debian branch then?

I'm basically fine with having multiple branches combined before writing
the patch queue. We "just" need to figure out the right UI:

* how to tell pq which branches it should care about and in what
  order (a simple ordered list of refs with a common merge-base)?
  We could use the topics as branch names.

* Do we still want to produce the linear view we currently have before
  exporting so the user sees the patch queue as is or do we rather want
  s.th. like "I have these 5 branches please serialize this into a
  patch queue". I'd opt for the later, we need to handle conflicts then
  as well though. We could reuse the ordered list from above.

Does this make sense? 
Cheers,
 -- Guido