control: retitle -1 Various fixes to dgit-maint-merge(7)
control: tag -1 +patch

Here are patches addressing all the points of our discussion.

-- 
Sean Whitton
From 95dc1a8b03f254ced683a4c0740a83c4ee275d7b Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhit...@spwhitton.name>
Date: Fri, 16 Jun 2017 13:04:58 +0100
Subject: [PATCH 1/4] dgit-maint-merge(7): Create an empty branch for upstream
 source

Thanks to Johannes Schauer for finding the problem.

Signed-off-by: Sean Whitton <spwhit...@spwhitton.name>
---
 dgit-maint-merge.7.pod | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index 901707e..995fe8b 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -148,12 +148,23 @@ Now create I<debian/gbp.conf>:
 
 =back
 
-Then we can import the upstream version:
+gbp-import-orig(1) requires a pre-existing upstream branch:
 
 =over 4
 
     % git add debian/gbp.conf && git commit -m "create gbp.conf"
-    % gbp import-orig ../foo_1.2.2.orig.tar.xz
+    % git checkout --orphan upstream
+    % git rm -rf .
+    % git commit --allow-empty -m "initial, empty branch for upstream source"
+    % git checkout -f master
+
+=back
+
+Then we can import the upstream version:
+
+=over 4
+
+    % gbp import-orig --merge-mode=replace ../foo_1.2.2.orig.tar.xz
 
 =back
 
-- 
2.15.0

From 8995d98aefc0a1a1125270039097253ff7fba75f Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhit...@spwhitton.name>
Date: Sat, 25 Nov 2017 16:56:14 -0700
Subject: [PATCH 2/4] dgit-maint-merge(7): Configure --merge-mode for
 gbp-import-orig(1)

For 3.0 (quilt) source packages, gbp-import-orig(1) defaults to
--merge-mode=replace, which does the wrong thing for patches-applied
repositories (see gbp-import-orig(1)).

Note that we do override this when importing the first upstream
version.  This is needed because git-merge(1) will refuse to merge
unrelated histories.

Thanks to Johannes Schauer for reporting the problem.

Signed-off-by: Sean Whitton <spwhit...@spwhitton.name>
---
 dgit-maint-merge.7.pod | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index 995fe8b..fe48609 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -146,6 +146,9 @@ Now create I<debian/gbp.conf>:
     pristine-tar = False
     pristine-tar-commit = False
 
+    [import-orig]
+    merge-mode = merge
+
 =back
 
 gbp-import-orig(1) requires a pre-existing upstream branch:
-- 
2.15.0

From aa08bdfb49fb0f24f593bc18a4285c3260f39407 Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhit...@spwhitton.name>
Date: Sat, 25 Nov 2017 17:13:32 -0700
Subject: [PATCH 3/4] dgit-maint-merge(7): Restructure "NEW UPSTREAM RELEASES"

Previously, some instructions applicable and needed whether or not
upstream tags releases in git were given only for the case where
upstream tags releases in git.

Thanks Johannes Schauer for noticing this problem.

Signed-off-by: Sean Whitton <spwhit...@spwhitton.name>
---
 dgit-maint-merge.7.pod | 56 ++++++++++++++++++++++++++++++++------------------
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index fe48609..ed7cdc0 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -309,58 +309,74 @@ to git), you can just run dpkg-buildpackage(1) or debuild(1) instead.
 
 =head1 NEW UPSTREAM RELEASES
 
-=head2 When upstream tags releases in git
+=head2 Obtaining the release
 
-It's a good idea to preview the merge of the new upstream release.
-First, just check for any new or deleted files that may need
-accounting for in your copyright file:
+=head3 When upstream tags releases in git
 
 =over 4
 
     % git remote update
-    % git diff --stat master..1.2.3 -- . ':!debian'
 
 =back
 
-You can then review the full merge diff:
+=head3 When upstream releases only tarballs
+
+You will need the I<debian/gbp.conf> from "When upstream releases only
+tarballs", above.
+
+Then, either
 
 =over 4
 
-    % git merge-tree `git merge-base master 1.2.3` master 1.2.3 | $PAGER
+    % gbp import-orig --no-merge ../foo_1.2.3.orig.tar.xz
 
 =back
 
-Once you're satisfied with what will be merged, update your package:
+or if you have a working watch file
 
 =over 4
 
-    % git merge 1.2.3
-    % dch -v1.2.3-1 New upstream release.
-    % git add debian/changelog && git commit -m changelog
-    % git deborig
+    % gbp import-orig --no-merge --uscan
 
 =back
 
-and you are ready to try a build.
+=head2 Reviewing & merging the release
 
-=head2 When upstream releases only tarballs
+It's a good idea to preview the merge of the new upstream release.
+First, just check for any new or deleted files that may need
+accounting for in your copyright file:
 
-You will need the I<debian/gbp.conf> from "When upstream releases only
-tarballs", above.
+=over 4
 
-Then, either
+    % git diff --stat master..1.2.3 -- . ':!debian'
+
+=back
+
+You can then review the full merge diff:
 
 =over 4
 
-    % gbp import-orig ../foo_1.2.2.orig.tar.xz
+    % git merge-tree `git merge-base master 1.2.3` master 1.2.3 | $PAGER
 
 =back
 
-or if you have a working watch file
+Once you're satisfied with what will be merged, update your package:
 
 =over 4
 
-    % gbp import-orig --uscan
+    % git merge 1.2.3
+    % dch -v1.2.3-1 New upstream release.
+    % git add debian/changelog && git commit -m changelog
+
+=back
+
+If you obtained a tarball from upstream, you are ready to try a build.
+If you merged a git tag from upstream, you will first need to generate
+a tarball:
+
+=over 4
+
+    % git deborig
 
 =back
 
-- 
2.15.0

From 0daa334a6528634a17f0b776dc0c7248460016d5 Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhit...@spwhitton.name>
Date: Sat, 25 Nov 2017 17:23:07 -0700
Subject: [PATCH 4/4] dgit-maint-merge(7): Mandate pushing upstream branch to
 alioth

In the case where we are using gbp-import-orig(1) to maintain a
virtual upstream branch, we must push that branch somewhere.  It is
needed whenever we import a new upstream release.

Thanks to Johannes Schauer for pointing out that the manpage
previously said that pushing to alioth is always optional.

Signed-off-by: Sean Whitton <spwhit...@spwhitton.name>
---
 dgit-maint-merge.7.pod | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index ed7cdc0..cb9fe4e 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -171,12 +171,9 @@ Then we can import the upstream version:
 
 =back
 
-You are now ready to proceed as above, making commits to both the
-upstream source and the I<debian/> directory.
-
-If you want to maintain a copy of your repository on
-B<alioth.debian.org>, you should push both the origin and the upstream
-branches:
+Our upstream branch cannot be pushed to B<dgit-repos>, but since we
+will need it whenever we import a new upstream version, we must push
+it somewhere.  The usual choice is B<alioth.debian.org>:
 
 =over 4
 
@@ -185,6 +182,9 @@ branches:
 
 =back
 
+You are now ready to proceed as above, making commits to both the
+upstream source and the I<debian/> directory.
+
 =head1 CONVERTING AN EXISTING PACKAGE
 
 This section explains how to convert an existing Debian package to
@@ -322,7 +322,9 @@ to git), you can just run dpkg-buildpackage(1) or debuild(1) instead.
 =head3 When upstream releases only tarballs
 
 You will need the I<debian/gbp.conf> from "When upstream releases only
-tarballs", above.
+tarballs", above.  You will also need your upstream branch.  Above, we
+pushed this to B<alioth.debian.org>.  You will need to clone or fetch
+from there, instead of relying on B<dgit clone>/B<dgit fetch> alone.
 
 Then, either
 
-- 
2.15.0

Attachment: signature.asc
Description: PGP signature

Reply via email to