X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=dgit-user.7.pod;h=aacdf4d4482dfa0a67d13422999ffc9b46cd00f1;hp=fc0d5905b2668c86bdbfdfb7ab7aeea2fc4f451f;hb=bada5f43152b731b980626f5f995da1899bc568d;hpb=a45f75bad000ac3230dace4291cda2e167d8102d diff --git a/dgit-user.7.pod b/dgit-user.7.pod index fc0d5905..aacdf4d4 100644 --- a/dgit-user.7.pod +++ b/dgit-user.7.pod @@ -30,7 +30,7 @@ or L and L. =over 4 - % dgit clone glibc jessie + % dgit clone glibc jessie,-security % cd glibc % wget 'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250;mbox=yes;msg=89' | patch -p1 -u % git commit -a -m 'Fix libc lost output bug' @@ -55,7 +55,7 @@ Later: =over 4 % cd glibc - % dgit pull jessie + % dgit pull jessie,-security % gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit % dpkg-buildpackage -uc -b % sudo dpkg -i ../libc6_*.deb @@ -66,7 +66,7 @@ Later: =over 4 - % dgit clone glibc jessie + % dgit clone glibc jessie,-security % cd glibc =back @@ -125,15 +125,23 @@ If you don't know what you're running, try this: =back +For Debian, you should add C<,-security> +to the end of the suite name, +unless you're on unstable or testing. +Hence, in our example +C becomes C. +(Yes, with a comma.) + =head1 WHAT DGIT CLONE PRODUCES =head2 What branches are there dgit clone will give you a new working tree, -and arrange for you to be on a branch like -C. +and arrange for you to be on a branch named like +C (yes, with a comma in the branch name). -There is a tracking branch for the contents of the archive, called +For each release (like C) +there is a tracking branch for the contents of the archive, called C (and similarly for other suites). This can be updated with C. @@ -141,6 +149,12 @@ This, the I, is synthesized by your local copy of dgit. It is fast forwarding. +Debian separates out the security updates, into C<*-security>. +Telling dgit C means that it should include +any updates available in C. +The comma notation is a request to dgit to track jessie, +or jessie-security if there is an update for the package there. + (You can also dgit fetch in a tree that wasn't made by dgit clone. If there's no C you'll have to supply a C<-p>I option to dgit fetch.) @@ -183,12 +197,15 @@ or upstream's git history. But for many packages the real git history does not exist, or has not been published in a dgitish form. -So yuu may find that the history is a rather short +So you may find that the history is a rather short history invented by dgit. dgit histories often contain automatically-generated commits, including commits which make no changes but just serve to make a rebasing branch fast-forward. +This is particularly true of +combining branches like +C. If the package maintainer is using git then after dgit clone @@ -215,9 +232,9 @@ that are in debian/patches before you do anything else! Debian package builds are often quite messy: they may modify files which are also committed to git, -or leave outputs and teporary files not covered by C<.gitignore>. +or leave outputs and temporary files not covered by C<.gitignore>. -Kf you always commit, +If you always commit, you can use =over 4 @@ -332,7 +349,7 @@ The proper solution is to build the package for all the architectures you have enabled. You'll need a chroot for each of the secondary architectures. -This iw somewhat tiresome, +This is somewhat tiresome, even though Debian has excellent tools for managing chroots. C from the sbuild package is a good starting point. @@ -345,9 +362,9 @@ If neither of those are an option, your desperate last resort is to try using the same version number as the official package for your own package. -(The verseion is controlled by C - see above,) +(The version is controlled by C - see above). This is not ideal because it makes it hard to tell what is installed, -because it will mislead and confuse apt. +and because it will mislead and confuse apt. With the "same number" approach you may still get errors like @@ -362,7 +379,7 @@ but passing C<--force-overwrite> to dpkg will help =head1 SHARING YOUR WORK -The C branch (or whatever) is a normal git branch. +The C branch (or whatever) is a normal git branch. You can use C to publish it on any suitable git server. Anyone who gets that git branch from you