|author||Sean Whitton <firstname.lastname@example.org>||2018-04-19 13:14:19 -0700|
|committer||Sean Whitton <email@example.com>||2018-04-19 13:15:15 -0700|
dgit-maint-debrebase(7): rewrite "Upstream branches" again
Suggested-by: Ian Jackson <firstname.lastname@example.org> Signed-off-by: Sean Whitton <email@example.com>
1 files changed, 14 insertions, 7 deletions
diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 297bf48..9157ee6 100644
@@ -567,15 +567,22 @@ than sending files from I<debian/patches>.
=head2 Upstream branches
-Except in the case where upstream releases only tarballs, or we
-require DFSG filtering, we do not maintain a separate 'upstream'
-branch (unless you also happen to be involved in upstream
-development). We work with upstream tags rather than any branches
-(except temporary branches used to prepare patches for forwarding
-upstream, for example).
+In this workflow, we specify upstream tags rather than any branches.
+Except when (i) upstream releases only tarballs, (ii) we require DFSG
+filtering, or (iii) you also happen to be involved in upstream
+development, we do not maintain any local branch corresponding to
+upstream, except temporary branches used to prepare patches for
+forwarding, and the like.
The idea here is that from Debian's point of view, upstream releases
-are immutable points in history, and so better represented by tags.
+are immutable points in history. We want to make sure that we are
+basing our Debian package on a properly identified upstream version,
+rather than some arbitrary commit on some branch. Tags are more
+useful for this.
+Upstream's branches remain available as the git remote tracking
+branches for your upstream remote, e.g. I<remotes/upstream/master>.
=head2 The first ever dgit push