1 # SOME DESCRIPTIVE TITLE
2 # Copyright (C) YEAR Free Software Foundation, Inc.
3 # This file is distributed under the same license as the PACKAGE package.
4 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
9 "Project-Id-Version: PACKAGE VERSION\n"
10 "POT-Creation-Date: 2019-07-21 01:37+0100\n"
11 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
12 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
13 "Language-Team: LANGUAGE <LL@li.org>\n"
16 "Content-Type: text/plain; charset=UTF-8\n"
17 "Content-Transfer-Encoding: 8bit\n"
20 #: ../dgit.1:2 ../dgit.7:1
26 #: ../dgit.1:2 ../dgit.7:1
28 msgid "Debian Project"
32 #: ../dgit.1:3 ../dgit.7:2 ../dgit-user.7.pod:1 ../dgit-nmu-simple.7.pod:1
33 #: ../dgit-maint-native.7.pod:1 ../dgit-maint-merge.7.pod:1
34 #: ../dgit-maint-gbp.7.pod:1 ../dgit-maint-debrebase.7.pod:1
35 #: ../dgit-downstream-dsc.7.pod:1 ../dgit-sponsorship.7.pod:1
36 #: ../dgit-maint-bpo.7.pod:1 ../git-debrebase.1.pod:1 ../git-debrebase.5.pod:1
37 #: ../git-debpush.1.pod:1
43 #: ../dgit.1:1549 ../dgit.7:23 ../dgit-user.7.pod:447
44 #: ../dgit-nmu-simple.7.pod:137 ../dgit-maint-native.7.pod:126
45 #: ../dgit-maint-merge.7.pod:521 ../dgit-maint-gbp.7.pod:136
46 #: ../dgit-maint-debrebase.7.pod:778 ../dgit-downstream-dsc.7.pod:352
47 #: ../dgit-sponsorship.7.pod:321 ../dgit-maint-bpo.7.pod:134
48 #: ../git-debrebase.1.pod:619 ../git-debrebase.5.pod:678
49 #: ../git-debpush.1.pod:223
56 msgid "dgit - principles of operation"
60 #: ../dgit.7:4 ../dgit-user.7.pod:27 ../dgit-nmu-simple.7.pod:35
68 "B<dgit> treats the Debian archive as a version control system, and "
69 "bidirectionally gateways between the archive and git. The git view of the "
70 "package can contain the usual upstream git history, and will be augmented by "
71 "commits representing uploads done by other developers not using dgit. This "
72 "git history is stored in a canonical location known as B<dgit-repos> which "
73 "lives on a dedicated git server."
79 "git branches suitable for use with dgit can be edited directly in git, and "
80 "used directly for building binary packages. They can be shared using all "
81 "conventional means for sharing git branches. It is not necessary to use "
82 "dgit to work with dgitish git branches. However, dgit is (usually) needed "
83 "in order to convert to or from Debian-format source packages."
94 msgid "Reference manual and documentation catalogue."
105 msgid "Tutorials and workflow guides. See dgit(1) for a list."
117 "You may use any suitable git workflow with dgit, provided you satisfy dgit's "
124 "dgit maintains a pseudo-remote called B<dgit>, with one branch per suite. "
125 "This remote cannot be used with plain git."
131 "The B<dgit-repos> repository for each package contains one ref per suite "
132 "named B<refs/dgit/>I<suite>. These should be pushed to only by dgit. They "
133 "are fast forwarding. Each push on this branch corresponds to an upload (or "
140 "However, it is perfectly fine to have other branches in dgit-repos; normally "
141 "the dgit-repos repo for the package will be accessible via the remote name "
148 "dgit push will also make signed tags called B<archive/debian/>I<version> "
149 "(with version encoded a la DEP-14) and push them to dgit-repos. These are "
150 "used at the server to authenticate pushes."
156 "Uploads made by dgit contain an additional field B<Dgit> in the source "
157 "package .dsc. (This is added by dgit push.) This specifies: a commit (an "
158 "ancestor of the dgit/suite branch) whose tree is identical to the unpacked "
159 "source upload; the distro to which the upload was made; a tag name which can "
160 "be used to fetch the git commits; and a url to use as a hint for the dgit "
161 "git server for that distro."
167 "Uploads not made by dgit are represented in git by commits which are "
168 "synthesised by dgit. The tree of each such commit corresponds to the "
169 "unpacked source; there is a commit with the contents, and a pseudo-merge "
170 "from last known upload - that is, from the contents of the dgit/suite "
171 "branch. Depending on the source package format, the contents commit may "
172 "have a more complex structure, but ultimately it will be a convergence of "
173 "stubby branches from origin commits representing the components of the "
180 "dgit expects trees that it works with to have a B<dgit> (pseudo) remote. "
181 "This refers to the dgit-created git view of the corresponding archive."
187 "The dgit archive tracking view is synthesised locally, on demand, by each "
188 "copy of dgit. The tracking view is always a descendant of the dgit-repos "
189 "suite branch (if one exists), but may be ahead of it if uploads have been "
190 "done without dgit. The archive tracking view is always fast forwarding "
197 "dgit push can operate on any commit which is a descendant of the suite "
204 "dgit does not make a systematic record of its imports of orig tarball(s). "
205 "So it does not work by finding git tags or branches referring to orig "
206 "tarball(s). The orig tarballs are downloaded (by dgit clone) into the "
207 "parent directory, as with a traditional (non-gitish) dpkg-source workflow. "
208 "You need to retain these tarballs in the parent directory for dgit build and "
209 "dgit push. (They are not needed for purely-git-based workflows.)"
215 "dgit repositories could be cloned with standard (git) methods. However, the "
216 "dgit repositories do not contain uploads not made with dgit. And for "
217 "sourceful builds / uploads the orig tarball(s) will need to be present in "
218 "the parent directory."
224 "To a user looking at the archive, changes pushed in a simple NMU using dgit "
225 "look like reasonable changes made in an NMU: in a `3.0 (quilt)' package the "
226 "delta from the previous upload is recorded in new patch(es) constructed by "
233 msgid "COMBINED SUITES"
239 "dgit can synthesize a combined view of several underlying suites. This is "
240 "requested by specifying, for I<suite,> a comma-separated list:"
245 msgid "I<mainsuite>B<,>I<subsuite>..."
250 msgid "This facility is available with dgit clone, fetch and pull, only."
256 "dgit will fetch the same package from each specified underlying suite, "
257 "separately (as if with dgit fetch). dgit will then generate a pseudomerge "
258 "commit on the tracking branch B<remotes/dgit/dgit/>I<suite> which has the "
259 "tip of each of the underlying suites as an ancestor, and which contains the "
260 "same as the suite which has the highest version of the package."
266 "The package must exist in mainsuite, but need not exist in the subsuites."
271 msgid "If a specified subsuite starts with B<-> then mainsuite is prepended."
277 "So, for example, B<stable,-security> means to look for the package in "
278 "stable, and stable-security, taking whichever is newer. If stable is "
279 "currently jessie, dgit clone would leave you on the branch B<dgit/jessie,-"
286 "Combined suites are not supported by the dgit build operations. This is "
287 "because those options are intended for building for uploading source "
288 "packages, and look in the changelog to find the relevant suite. It does not "
289 "make sense to name a dgit-synthesised combined suite in a changelog, or to "
290 "try to upload to it."
296 "When using this facility, it is important to always specify the same suites "
297 "in the same order: dgit will not make a coherent fast-forwarding history "
304 "The history generated by this feature is not normally suitable for merging "
305 "back into upstreams, as it necessarily contains unattractive pseudomerges."
317 "Because the synthesis of the suite tracking branches is done locally based "
318 "only on the current archive state, it will not necessarily see every upload "
319 "not done with dgit. Also, different versions of dgit (or the software it "
320 "calls) might import the same .dscs differently (although we try to minimise "
321 "this). As a consequence, the dgit tracking views of the same suite, made by "
322 "different instances of dgit, may vary. They will have the same contents, "
323 "but may have different history."
329 "There is no uniform linkage between the tracking branches for different "
330 "suites. The Debian infrastructure does not do any automatic import of "
331 "uploads made without dgit. It would be possible for a distro's "
332 "infrastructure to do this; in that case, different dgit client instances "
333 "would see exactly the same history."
339 "There has been no bulk import of historical uploads into Debian's dgit "
340 "infrastructure. To do this it would be necessary to decide whether to "
341 "import existing vcs history (which might not be faithful to dgit's "
342 "invariants) or previous non-Dgit uploads (which would not provide a very "
349 "git represents only file executability. git does not represent empty "
350 "directories, or any leaf objects other than plain files and symlinks. The "
351 "behaviour of Debian source package formats on objects with unusual "
352 "permissions is complicated. Some pathological Debian source packages will "
353 "no longer build if empty directories are pruned (or if other things not "
354 "reproduced by git are changed). Such sources cannot be worked with properly "
355 "in git, and therefore not with dgit either."
361 msgid "READ-ONLY DISTROS"
367 "Distros which do not maintain a set of dgit history git repositories can "
368 "still be used in a read-only mode with dgit. Currently Ubuntu is configured "
375 msgid "GITATTRIBUTES"
381 "git has features which can automatically transform files as they are being "
382 "copied between the working tree and the git history. The attributes can be "
383 "specified in the source tree itself, in B<.gitattributes>. See "
384 "B<gitattributes>(5)."
390 "These transformations are context-sensitive and not, in general, reversible, "
391 "so dgit operates on the principle that the dgit git history contains the "
392 "actual contents of the package. (When dgit is manipulating a .dsc, it does "
393 "so in a private area, where the transforming gitattributes are defused, to "
400 "If transforming gitattributes are used, they can cause trouble, because the "
401 "working tree files can differ from the git revision history (and therefore "
402 "from the source packages). dgit warns if it finds a .gitattributes file (in "
403 "a package being fetched or imported), unless the transforming gitattributes "
410 "dgit clone and dgit setup-new-tree disable transforming gitattributes by "
411 "default, by creating a suitable .git/info/attributes. See B<dgit setup-new-"
412 "tree> and B<dgit setup-gitattributes> in dgit(1)."
418 "Note that dgit does not disable gitattributes unless they would actually "
419 "interfere with your work on dgit branches. In particular, gitattributes "
420 "which affect B<git archive> are not disabled, so .origs you generate by hand "
421 "can be wrong. You should consider using B<git-deborig (1)> which gets this "
422 "right, suppressing the attributes."
428 msgid "PACKAGE SOURCE FORMATS"
434 "If you are not the maintainer, you do not need to worry about the source "
435 "format of the package. You can just make changes as you like in git. If "
436 "the package is a `3.0 (quilt)' package, the patch stack will usually not be "
437 "represented in the git history."
443 msgid "FILE EXECUTABILITY"
449 "Debian source package formats do not always faithfully reproduce changes to "
450 "executability. But dgit insists that the result of dgit clone is identical "
451 "(as far as git can represent - see Limitations, above) to the result of "
458 "So files that are executable in your git tree must be executable in the "
459 "result of dpkg-source -x (but often aren't). If a package has such "
460 "troublesome files, they have to be non-executable in dgit-compatible git "
467 msgid "FORMAT 3.0 (QUILT)"
473 "For a format `3.0 (quilt)' source package, dgit may have to make a commit on "
474 "your current branch to contain metadata used by quilt and dpkg-source."
480 "This is because `3.0 (quilt)' source format represents the patch stack as "
481 "files in debian/patches/ actually inside the source tree. This means that, "
482 "taking the whole tree (as seen by git or ls) (i) dpkg-source cannot "
483 "represent certain trees, and (ii) packing up a tree in `3.0 (quilt)' and "
484 "then unpacking it does not always yield the same tree."
490 "dgit will automatically work around this for you when building and pushing. "
491 "The only thing you need to know is that dgit build, sbuild, etc., may make "
492 "new commits on your HEAD. If you're not a quilt user this commit won't "
493 "contain any changes to files you care about."
499 "Simply committing to source files (whether in debian/ or not, but not to "
500 "patches) will result in a branch that dgit quilt-fixup can linearise. "
501 "Other kinds of changes, including editing patches or merging, cannot be "
508 "You can explicitly request that dgit do just this fixup, by running dgit "
515 "If you are a quilt user you need to know that dgit's git trees are `patches "
516 "applied packaging branches' and do not contain the .pc directory (which is "
517 "used by quilt to record which patches are applied). If you want to "
518 "manipulate the patch stack you probably want to be looking at tools like git-"
519 "debrebase, gbp pq, or git-dpm."
525 msgid "quilt fixup error messages"
530 msgid "When dgit's quilt fixup fails, it prints messages like this:"
537 "dgit: base trees orig=5531f03d8456b702eab6 o+d/p=135338e9cc253cc85f84\n"
538 "dgit: quilt differences: src: == orig ## gitignores: == orig ##\n"
539 "dgit: quilt differences: HEAD ## o+d/p HEAD ## o+d/p\n"
540 "starting quiltify (multiple patches, linear mode)\n"
547 "dgit: error: quilt fixup cannot be linear. Stopped at:\n"
548 "dgit: 696c9bd5..84ae8f96: changed debian/patches/test-gitignore\n"
560 "is an import of the .orig tarballs dgit found, with the debian/ directory "
561 "from your HEAD substituted. This is a git tree object, not a commit: you "
562 "can pass its hash to git-diff but not git-log."
574 "is another tree object, which is the same as orig but with the patches from "
575 "debian/patches applied."
586 msgid "is of course your own git HEAD."
592 msgid "B<quilt differences>"
598 "shows whether each of the these trees differs from the others (i) in "
599 "upstream files excluding .gitignore files; (ii) in upstream .gitignore "
600 "files. B<==> indicates equality; B<##> indicates inequality."
606 "dgit quilt-fixup --quilt=linear walks commits backwards from your HEAD "
607 "trying to construct a linear set of additional patches, starting at the "
608 "end. It hopes to eventually find an ancestor whose tree is identical to o+d/"
609 "p in all upstream files."
615 "In the error message, 696c9bd5..84ae8f96 is the first commit child-parent "
616 "edge which cannot sensibly be either ignored, or turned into a patch in "
617 "debian/patches. In this example, this is because it itself changes files in "
618 "debian/patches, indicating that something unusual is going on and that "
619 "continuing is not safe. But you might also see other kinds of troublesome "
626 "Your appropriate response depends on the cause and the context. If you have "
627 "been freely merging your git branch and do not need need a pretty linear "
628 "patch queue, you can use B<--quilt=smash> (or use the B<1.0> or B<single-"
629 "debian-patch> source formats; see B<dpkg-source(1)>.) If you want a pretty "
630 "linear series, and this message is unexpected, it can mean that you have "
631 "unwittingly committed changes that are not representable by dpkg-source "
632 "(such as some mode changes). Or maybe you just forgot a necessary B<--"
639 "Finally, this problem can occur if you have provided Debian git tooling such "
640 "as git-debrebase, git-dpm or git-buildpackage with upstream git commit(s) or "
641 "tag(s) which are not 100% identical to your orig tarball(s)."
647 msgid "SPLIT VIEW AND SPLITTING QUILT MODES"
653 "When working with git branches intended for use with the `3.0 (quilt)' "
654 "source format dgit can automatically convert a suitable maintainer-provided "
655 "git branch (in one of a variety of formats) into a dgit branch."
661 "When a splitting quilt mode is selected dgit build commands and dgit push "
662 "will, on each invocation, convert the user's HEAD into the dgit view, so "
663 "that it can be built and/or uploaded."
669 "Split view mode can also be enabled explicitly with the --split-view command "
670 "line option and the .split-view access configuration key."
676 "When split view is in operation, regardless of the quilt mode, any dgit-"
677 "generated pseudomerges and any quilt fixup commits will appear only in the "
678 "dgit view. dgit push will push the dgit view to the dgit git server. The "
679 "dgit view is always a descendant of the maintainer view. dgit push will "
680 "also make a maintainer view tag according to DEP-14 and push that to the "
687 "Splitting quilt modes must be enabled explicitly (by the use of the "
688 "applicable command line options, subcommands, or configuration). This is "
689 "because it is not possible to reliably tell (for example) whether a git "
690 "tree for a dpkg-source `3.0 (quilt)' package is a patches-applied or patches-"
697 "Split view conversions are cached in the ref dgit-intern/quilt-cache. This "
698 "should not be manipulated directly."
704 msgid "FILES IN THE ORIG TARBALL BUT NOT IN GIT - AUTOTOOLS ETC."
710 "This section is mainly of interest to maintainers who want to use dgit with "
711 "their existing git history for the Debian package."
717 "Some developers like to have an extra-clean git tree which lacks files which "
718 "are normally found in source tarballs and therefore in Debian source "
719 "packages. For example, it is conventional to ship ./configure in the source "
720 "tarball, but some people prefer not to have it present in the git view of "
727 "dgit requires that the source package unpacks to exactly the same files as "
728 "are in the git commit on which dgit push operates. So if you just try to "
729 "dgit push directly from one of these extra-clean git branches, it will fail."
734 msgid "As the maintainer you therefore have the following options:"
738 #: ../dgit.7:457 ../dgit.7:468 ../dgit.7:517 ../dgit.7:525
746 "Delete the files from your git branches, and your Debian source packages, "
747 "and carry the deletion as a delta from upstream. (With `3.0 (quilt)' this "
748 "means representing the deletions as patches. You may need to pass --include-"
749 "removal to dpkg-source --commit, or pass corresponding options to other "
750 "tools.) This can make the Debian source package less useful for people "
751 "without Debian build infrastructure."
757 "Persuade upstream that the source code in their git history and the source "
758 "they ship as tarballs should be identical. Of course simply removing the "
759 "files from the tarball may make the tarball hard for people to use."
765 "One answer is to commit the (maybe autogenerated) files, perhaps with some "
766 "simple automation to deal with conflicts and spurious changes. This has the "
767 "advantage that someone who clones the git repository finds the program just "
768 "as easy to build as someone who uses the tarball."
774 "Of course it may also be that the differences are due to build system bugs, "
775 "which cause unintended files to end up in the source package. dgit will "
776 "notice this and complain. You may have to fix these bugs before you can "
777 "unify your existing git history with dgit's."
783 msgid "FILES IN THE SOURCE PACKAGE BUT NOT IN GIT - DOCS, BINARIES ETC."
789 "Some upstream tarballs contain build artifacts which upstream expects some "
790 "users not to want to rebuild (or indeed to find hard to rebuild), but which "
791 "in Debian we always rebuild."
797 "Examples sometimes include crossbuild firmware binaries and documentation. "
798 "To avoid problems when building updated source packages (in particular, to "
799 "avoid trying to represent as changes in the source package uninteresting or "
800 "perhaps unrepresentable changes to such files) many maintainers arrange for "
801 "the package clean target to delete these files."
807 "dpkg-source does not (with any of the commonly used source formats) "
808 "represent deletion of binaries (outside debian/) present in upstream. Thus "
809 "deleting such files in a dpkg-source working tree does not actually result "
810 "in them being deleted from the source package. Thus deleting the files in "
811 "rules clean sweeps this problem under the rug."
817 "However, git does always properly record file deletion. Since dgit's "
818 "principle is that the dgit git tree is the same of dpkg-source -x, that "
819 "means that a dgit-compatible git tree always contains these files."
825 "For the non-maintainer, this can be observed in the following suboptimal "
832 "The package clean target often deletes these files, making the git tree "
833 "dirty trying to build the source package, etc. This can be fixed by using "
834 "B<dgit -wg> aka B<--clean=git>, so that the package clean target is never "
841 "The package build modifies these files, so that builds make the git tree "
842 "dirty. This can be worked around by using `git reset --hard' after each "
843 "build (or at least before each commit or push)."
849 "From the maintainer's point of view, the main consequence is that to make a "
850 "dgit-compatible git branch it is necessary to commit these files to git. "
851 "The maintainer has a few additional options for mitigation: for example, it "
852 "may be possible for the rules file to arrange to do the build in a temporary "
853 "area, which avoids updating the troublesome files; they can then be left in "
854 "the git tree without seeing trouble."
860 msgid "PROBLEMS WITH PACKAGE CLEAN TARGETS ETC."
866 "A related problem is other unexpected behaviour by a package's B<clean> "
867 "target. If a package's rules modify files which are distributed in the "
868 "package, or simply forget to remove certain files, dgit will complain that "
875 "Again, the solution is to use B<dgit -wg> aka B<--clean=git>, which "
876 "instructs dgit to use git clean instead of the package's build target, along "
877 "with perhaps B<git reset --hard> before each build."
883 "This is 100% reliable, but has the downside that if you forget to git add or "
884 "to commit, and then use B<dgit -wg> or B<git reset --hard>, your changes may "
~ianmdlvl / dgit.git / blob