Hi,
On Mon, Apr 01, 2019 at 06:05:28PM +0100, Ian Jackson wrote:
> 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:
No problem ;-) This is more like a food-for-thought bug.
I am not particular about the use of dgit-maint-merge.
> > 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.
As a starter, I wrote a very broad vague wishlist. At the same time, I
understand this is a hard problem if this needs to be automatic for all
the use case.
> 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.
Let's make this simple by limiting the functionality of this wishlist
utility tool, say "dgit cherries", to function for a simple case. Let
me try with following ascii art.
human actions
X release
~ commit
+ merge
actions by "dgit cherries" on upstream
= commit (simple cherry picking)
: commit (dropping debian/* part with modified message)
. no-commit no change
First, You are upstream and released upstream package 1.0
1.0
upstream ~~~~~~~~X
Then, packaged 1.0-1 *without* any change to upstream source.
1.0
upstream ~~~~~~~~X
\
debian ----------+~~~X
1.0-1
Then, patched upstream part and released as 1.0-2, 1.0-3 as bug fix
version by changing upstream part on debian branch.
1.0
upstream ~~~~~~~~X
\
debian ----------+~~~X~~~~~~X~~~~~~X
1.0-1 1.0-2 1.0-3
Then, found major bug and locally created 1.0-4 by committing to debian
branch. This is very convenient ;-)
1.0
upstream ~~~~~~~~O
\
debian ----------+~~~X~~~~~~X~~~~~~X~~~~~~~~~~X
1.0-1 1.0-2 1.0-3 1.0-4
You can verify your idea for major change worked with 1.0-4.
You decide not to release it as Debian revision 1.0-4 but as a new
upstream source 1.1. Here, I think "dgit cherries" may be useful.
When HEAD is at 1.0-4 on debian branch, let's run "dgit cherries".
"dgit cherries" can find previous merge point "+".
Let "dgit cherries" cherry pick and apply cherry to the parent of merge
point on upstream branch. In this example, "O" is the point.
If change in debian branch commit doesn't include debian/* files, cherry
is applied with the original commit message and move on to next commit
on debian branch.
If change includes debian/* files, that part of cherry should be dropped
and remaining cherry should be applied with the commit message modified
to indicate change to debian/* files are not included. Then move on to
next commit on debian branch.
If change is only debian/* files, ignore that cherry and move on to next
commit on debian branch.
After all these are done, we should have
1.0
upstream ~~~~~~~~O==.==:==...===.=.=.==...==.=.
\
debian ----------+~~~X~~~~~~X~~~~~~X~~~~~~~~~~X
1.0-1 1.0-2 1.0-3 1.0-4
This is the end point of "dgit cherries" in my POV.
Now, You being the upstream do whatever (rebase to merge and clean up
original change history or add more original changes.). Then release
upstream 1.1. (This usually involves changing some part of upstream
code manually to bump its version from 1.0 to 1.1. Also, you may wish
to update some documentation etc in upstream source now.)
1.0 1.1
upstream ~~~~~~~~O==.=~:==-~~-~==.=.=.=~-----.=.~~~~~~~~O
\
debian ----------+~~~X~~~~~~X~~~~~~X~~~~~~~~~~X
1.0-1 1.0-2 1.0-3 1.0-4
Then you package 1.1-1 by merging upstream to debian as follows.
1.0 1.1
upstream ~~~~~~~~O==.==:==...===.=.=.==...==.=.~~~~~~~~O
\ \
debian ----------+~~~X~~~~~~X~~~~~~X~~~~~~~~~~X--------+~~~X
1.0-1 1.0-2 1.0-3 1.0-4 1.1-1
> (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.)
Well, I hope above use case explanation assumes clean -1 packaging. I
thought that can be done only when DM is upstream. Of course DM can
package with patch for -1. Let's ignore that kind of stupid case. If
you are upstream, you can release upstream sorce which doesn't require
debian patch initially. Besides, smart debian/rules file can
accommodate Debian specific build etc..
> > |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.
This was quoted text. Complete automation is too complicated.
I am limiting DD=upstream case as I mentioned in the above.
> 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.
If I cherry pick, I usually use gitk and done. Then we can create git
diff to send patch. That's needed when you are not upstream.
Actually, "dgit cherries" can create series of pasches on upstream
branch if -1 didn't have problematic patch.
You can do rebase after "dgit cherries" to clean up history and make
nice series of patches to be sent to upstream
> > | 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.
Yes, that is why "dgit cherries" ends at the point I mentioned above.
> > 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.
Here, I am not sure. But at least for the case I mentioned, it looks
simple enough and still useful.
> 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.
Maybe ... git-debrebase may provide even more flexible platform for
above case. But if -1 always have no patch file, any difference?
I concur that we need to give good consideration.
> 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
You may be correct.
But I had an impression we are talking different things. I am talking
actions to create upstream patches in the above list. I think
git-debrebase does these action when you merge changed upstream to
debian.
> 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.
Hmmm.. maybe restriction to -1 package may be lifted. You may have a
very good point here.
> 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.
I think use of extended git-debrebase or dgit-maint-merge workflow is
not important point. But enabling an variant of above mentioned work
flow is what I want ;-)
Osamu
