Osamu Aoki writes ("Bug#926181: want automatic forwarding of patches to the
upstream branch"):
> Package: dgit
> Version: 8.4
> Severity: wishlist
Hi. Thanks for your message. I'm always interested in hearing what
people want so please don't be discouraged by what I say next:
> In case of the Debian maintainer is the same person as the upstream
> maintainer, I would like to see automatic support to the operation
> described in dgit-maint-merge(7). This is nice alternative to native
> package workflow and nice upstream history.
I am struggling to understand how you think this could work
automatically. The biggest problem is that the data model in
dgit-maint-merge(7) does not necessarily break the Debian delta into
individual commits.
Also a problem is that I don't think there is an easy way of
discovering what the upstream is like and how to submit patches there.
(As an aside: I don't think any of this depends on whether the Debian
maintainer is the same person as the upstream with a different hat
on.)
> |FORWARDING PATCHES UPSTREAM
> | The basic steps are:
> |
> | 1. Create a new branch based off upstream's master branch.
> | 3. Push the branch somewhere and ask upstream to merge it, or use
> git-format-patch(1) or git-request-pull(1).
So (taking things out of order) these require knowing what the
upstream is and how to find its master branch and submit a merge
request.
It's true that we do have some metadata conventions for this kind of
thing in Debian. But maybe the task of automating steps 1 and 3
should be a separate program, in devscripts maybe ? It doesn't seem
dgit specific.
> | 2. git-cherry-pick(1) commits from your master branch onto your new branch.
This is the hardest part. I think in general only the maintainer will
know what commit(s) to cherry-pick.
> I want automated operation which goes like:
You seem to think that with dgit-maint-merge(7) there is a nice linear
list of the commits which are in Debian but not upstream. But there
isn't: in the general case, there is a lot of merging and the only
reasonably condensed representation of the Debian delta is the output
of `git diff' between the upstream and Debian branches.
I think what you really want to make this easy is a different data
model. Have you looked at git-debrebase or gbp pq ? Both of those
maintain the Debian delta as a linear series of commits.
git-debrebase already knows how to do many of the manipulations you
describe. For example:
> * for commit changing within debian/* only
> --> ignore
> * for commit changing outside of debian/* only
> --> apply as is with the same commit messages
> * for commit changing everything
> --> apply changes outside of debian/*
> --> use the same commit message
git-debrebase already knows how to separate commits out into "Debian"
parts and "upstream files" parts, and can split a "mixed" commit into
its two halves. So it can leave you with a tidy delta queue.
Perhaps there should be a
git-debrebase list
which shows you the delta queue and maybe some of your other
suggestions might make good git-debrebase features.
I hope my explanations make some kind of sense. If not maybe we need
a less formal but more interactive channel such as irc; feel free to
look for me as Diziet on oftc and freenode.
Ian.
