I was using git, fallowed by git format-patch, fallowed by adding the
quilt patches, and found this non-ideal, so I decided to try out gbp-pq.

However, I have found it to be non-ideal for a number of reasons.

1. gbp-pq rebase is not intelligent enough to handle non-fast-forward histories
 It will not search the reflog, etc, and then ends up doing this insane spitting out
of all patches on the current branch, when at the least it should spit out a warning.
I then find myself manually rebasing the patch-queue/foo branch to foo all the time.


2. gbp-pq doesn't support a patch queue that is right on top of the upstream,
or more generally, where the patch queue branch is not a fast forward of the branch it is
a patch queue for. It should be able to handle a patch queue branch that has at least
one shared ancestor with the branch being exported to. It could export by
 1. doing a recursive git merge, and if there are conflicts, letting git do what it is
    strong at: merging

and then when the merge is complete
 2. reset the branch to where it just was, and replace the patches in debian/patches with
    the result of the merge.

It could alternatively abort on merge conflicts, but I think letting the user use git to do this merge
could be quite useful, and make it more powerful than quilt.

I tried to just bypass gbp-pq by using git format-patch upstream/version..patch-queue/branch ,
but having a tool with knowledge of the series file for ordering of patches, instead of 0001, 0002,
etc is a "nice to have".

The whole rebasing and patch-queue handling would be much cleaner if the
patch-queue branch was based on the merge-base of the branch that should
contain the debian packaging (e.g. master) and the upstream branch (e.g.
upstream).

I.e. gbp-pq could do the following for import:

  * current = current branch
  * pq-name = "patch-queue/$current"
  * upstream = upstream-branch from gbp.conf or "upstream"
  * base = git merge-base $current $upstream
  * git checkout -b $pq-name $base
  * apply patches

gbp-pq export could then do:

  * current = current branch
  * pq-name = "patch-queue/$current"
  * upstream = upstream-branch from gbp.conf or "upstream"
  * base = git merge-base $pg-name $upstream
  * git-format patch -o debian/patches $base..$pq-name

and gbp-rebase finally could do:

  * current = current branch
  * pq-name = "patch-queue/$current"
  * upstream = upstream-branch from gbp.conf or "upstream"
  * old-base = git merge-base $pg-name $upstream
  * new-base = git merge-base $current $upstream
  * git rebase --onto $new-base $old-base $pq-name

This is much more rebase-friendly and ensures that the patches only
operate on upstream contents. They need not be aware of all the things
going on in the debian packaging branch in the first place.

Control: severity -1 normal
Control: retitle -1: patch-queues managed by gpb-pq should be based on upstream (and more suggestions)

Full ack. It's weird to have "gbp-pq export" generate patches for
debian packaging commit just because the patch-queue branch has not
yet been rebased on top of the (latest) packaging branch (and this even
though the underlying upstream version has not changed).

The suggested operations seem fine and logical to me.

Cheers,

Hi everyone,

I had this issue for some times with gbp-pq (what a hard command to
type…). For me, the problem is that the "branch...patch-queue/branch"
commit range is silly: gitrevisions(7) tells that it includes both
commits reachable from either branch, but not both. I don't know why
this was chosen, it doesn't correspond to what I thought this command
did. Incidentally, the "branch..patch-queue/branch" syntax seems to do
exactly what we want: start from the merge base, only walking along the
second branch.

I'm still not at ease with gbp-pq and not very good at Debian packaging,
so maybe this is wrong, but the attached patch may fix this problem.

Regards,

Hi Benjamin,

Hopefulle "gbp pq" is abit easier to type.
slightly different version.

Thanks!
 -- Guido

P.S.: I'll leave the bug open since there's more we can do to optimize
the rebase itself.