X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=dgit-maint-merge.7.pod;h=245be4c937a744cffd16bdc7a8f709b056cd1ce3;hp=d9dcb51075fa91ddca8a74c4c5225df7ea5e622d;hb=d4f8df7adccd9ed9a0dd1cd1837ed7782557a828;hpb=b6c1636360fdbfb9461635241ee6f6bef7fed964 diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod index d9dcb510..245be4c9 100644 --- a/dgit-maint-merge.7.pod +++ b/dgit-maint-merge.7.pod @@ -16,8 +16,6 @@ Git histories should be the non-linear histories produced by git-merge(1), preserving all information about divergent development that was later brought together. -If you prefer linear histories, see dgit-maint-rebase(7). - =item Maintaining convenient and powerful git workflows takes priority over @@ -52,6 +50,10 @@ compress orig tarballs: =head1 INITIAL DEBIANISATION +This section explains how to start using this workflow with a new +package. It should be skipped when converting an existing package to +this workflow. + =head2 When upstream tags releases in git Suppose that the latest stable upstream release is 1.2.2, and this has @@ -106,6 +108,23 @@ with 'gz'. This tarball is ephemeral and easily regenerated, so we don't commit it anywhere (e.g. with tools like pristine-tar(1)). +=head3 Verifying upstream's tarball releases + +=over 4 + +It can be a good idea to compare upstream's released tarballs with the +release tags, at least for the first upload of the package. If they +are different, you might need to add some additional steps to your +I, such as running autotools. + +A convenient way to perform this check is to import the tarball as +described in the following section, using a different value for +'upstream-tag', and then use git-diff(1) to compare the imported +tarball to the release tag. If they are the same, you can use +upstream's tarball instead of running git-archive(1). + +=back + =head2 When upstream releases only tarballs We need a virtual upstream branch with virtual release tags. @@ -124,7 +143,7 @@ Now create I: =over 4 [DEFAULT] - upstream-branch = upsteram + upstream-branch = upstream debian-branch = master upstream-tag = %(version)s @@ -157,6 +176,50 @@ branches: =back +=head1 CONVERTING AN EXISTING PACKAGE + +This section explains how to convert an existing Debian package to +this workflow. It should be skipped when debianising a new package. + +=head2 No existing git history + +=over 4 + + % dgit clone foo + % cd foo + % git remote add -f upstream https://some.upstream/foo.git + +=back + +=head2 Existing git history using another workflow + +First, dump any existing patch queue: + +=over 4 + + % git rm -rf debian/patches + % git commit -m "drop existing quilt patch queue" + +=back + +Then make new upstream tags available: + +=over 4 + + % git remote add -f upstream https://some.upstream/foo.git + +=back + +Now you simply need to ensure that your git HEAD is dgit-compatible, +i.e., it is exactly what you would get if you ran B and then unpacked the resultant source package. + +To achieve this, you might need to delete +I. One way to have dgit check your +progress is to run B. + +The first dgit push will require I<--overwrite>. + =head1 SOURCE PACKAGE CONFIGURATION =head2 debian/source/options @@ -175,7 +238,7 @@ source: You don't need to create this file if you are using the version 1.0 source package format. -=head2 Sample text for README.source +=head2 Sample text for debian/source/patch-header It is a good idea to explain how a user can obtain a break down of the changes to the upstream source: @@ -184,7 +247,7 @@ changes to the upstream source: The Debian packaging of foo is maintained using dgit. For the sake of an efficient workflow, Debian modifications to the upstream source are -squashed into a single patch, rather than a series of quilt patches. +squashed into a single diff, rather than a series of quilt patches. To obtain a patch queue for package version 1.2.3-1: =over 4 @@ -200,6 +263,10 @@ See dgit(1), dgit(7) and dgit-maint-merge(7) for more information. =back +Alternatively, this text could be added to README.source. However, +this might distract from more important information present in the +latter file. + =head1 BUILDING AND UPLOADING Use B, B, B, and B from "When upstream releases only +tarballs", above. + +Then, either =over 4 @@ -296,7 +366,12 @@ We create a DFSG-clean tag to merge to master: Before merging the new 1.2.3+dfsg tag to master, you should first determine whether it would be legally dangerous for the non-free material to be publicly accessible in the git history on -B. If it would be, pass B<--squash> to git-merge(1). +B. + +If it would be dangerous, there is a big problem; +in this case please consult your archive administrators +(for Debian this is the dgit administrator dgit-owner@debian.org +and the ftpmasters ftpmaster@ftp-master.debian.org). =head2 When upstream releases only tarballs @@ -362,4 +437,4 @@ dgit(1), dgit(7) =head1 AUTHOR -This tutorial was written and is maintained by Sean Whitton . +This tutorial was written and is maintained by Sean Whitton . It contains contributions from other dgit contributors too - see the dgit copyright file.