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: 2018-10-04 01:04+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 #: ../git-debrebase.1.pod:1 ../git-debrebase.5.pod:1
42 #: ../dgit.1:1394 ../dgit.7:23 ../dgit-user.7.pod:447
43 #: ../dgit-nmu-simple.7.pod:137 ../dgit-maint-native.7.pod:126
44 #: ../dgit-maint-merge.7.pod:491 ../dgit-maint-gbp.7.pod:136
45 #: ../dgit-maint-debrebase.7.pod:722 ../dgit-downstream-dsc.7.pod:352
46 #: ../dgit-sponsorship.7.pod:321 ../git-debrebase.1.pod:601
47 #: ../git-debrebase.5.pod:678
54 msgid "dgit - principles of operation"
58 #: ../dgit.7:4 ../dgit-user.7.pod:27 ../dgit-nmu-simple.7.pod:35
66 "B<dgit> treats the Debian archive as a version control system, and "
67 "bidirectionally gateways between the archive and git. The git view of the "
68 "package can contain the usual upstream git history, and will be augmented by "
69 "commits representing uploads done by other developers not using dgit. This "
70 "git history is stored in a canonical location known as B<dgit-repos> which "
71 "lives on a dedicated git server."
77 "git branches suitable for use with dgit can be edited directly in git, and "
78 "used directly for building binary packages. They can be shared using all "
79 "conventional means for sharing git branches. It is not necessary to use "
80 "dgit to work with dgitish git branches. However, dgit is (usually) needed "
81 "in order to convert to or from Debian-format source packages."
92 msgid "Reference manual and documentation catalogue."
103 msgid "Tutorials and workflow guides. See dgit(1) for a list."
115 "You may use any suitable git workflow with dgit, provided you satisfy dgit's "
122 "dgit maintains a pseudo-remote called B<dgit>, with one branch per suite. "
123 "This remote cannot be used with plain git."
129 "The B<dgit-repos> repository for each package contains one ref per suite "
130 "named B<refs/dgit/>I<suite>. These should be pushed to only by dgit. They "
131 "are fast forwarding. Each push on this branch corresponds to an upload (or "
138 "However, it is perfectly fine to have other branches in dgit-repos; normally "
139 "the dgit-repos repo for the package will be accessible via the remote name "
146 "dgit push will also make signed tags called B<archive/debian/>I<version> "
147 "(with version encoded a la DEP-14) and push them to dgit-repos. These are "
148 "used at the server to authenticate pushes."
154 "Uploads made by dgit contain an additional field B<Dgit> in the source "
155 "package .dsc. (This is added by dgit push.) This specifies: a commit (an "
156 "ancestor of the dgit/suite branch) whose tree is identical to the unpacked "
157 "source upload; the distro to which the upload was made; a tag name which can "
158 "be used to fetch the git commits; and a url to use as a hint for the dgit "
159 "git server for that distro."
165 "Uploads not made by dgit are represented in git by commits which are "
166 "synthesised by dgit. The tree of each such commit corresponds to the "
167 "unpacked source; there is a commit with the contents, and a pseudo-merge "
168 "from last known upload - that is, from the contents of the dgit/suite "
169 "branch. Depending on the source package format, the contents commit may "
170 "have a more complex structure, but ultimately it will be a convergence of "
171 "stubby branches from origin commits representing the components of the "
178 "dgit expects trees that it works with to have a B<dgit> (pseudo) remote. "
179 "This refers to the dgit-created git view of the corresponding archive."
185 "The dgit archive tracking view is synthesised locally, on demand, by each "
186 "copy of dgit. The tracking view is always a descendant of the dgit-repos "
187 "suite branch (if one exists), but may be ahead of it if uploads have been "
188 "done without dgit. The archive tracking view is always fast forwarding "
195 "dgit push can operate on any commit which is a descendant of the suite "
202 "dgit does not make a systematic record of its imports of orig tarball(s). "
203 "So it does not work by finding git tags or branches referring to orig "
204 "tarball(s). The orig tarballs are downloaded (by dgit clone) into the "
205 "parent directory, as with a traditional (non-gitish) dpkg-source workflow. "
206 "You need to retain these tarballs in the parent directory for dgit build and "
207 "dgit push. (They are not needed for purely-git-based workflows.)"
213 "dgit repositories could be cloned with standard (git) methods. However, the "
214 "dgit repositories do not contain uploads not made with dgit. And for "
215 "sourceful builds / uploads the orig tarball(s) will need to be present in "
216 "the parent directory."
222 "To a user looking at the archive, changes pushed in a simple NMU using dgit "
223 "look like reasonable changes made in an NMU: in a `3.0 (quilt)' package the "
224 "delta from the previous upload is recorded in new patch(es) constructed by "
231 msgid "COMBINED SUITES"
237 "dgit can synthesize a combined view of several underlying suites. This is "
238 "requested by specifying, for I<suite,> a comma-separated list:"
243 msgid "I<mainsuite>B<,>I<subsuite>..."
248 msgid "This facility is available with dgit clone, fetch and pull, only."
254 "dgit will fetch the same package from each specified underlying suite, "
255 "separately (as if with dgit fetch). dgit will then generate a pseudomerge "
256 "commit on the tracking branch B<remotes/dgit/dgit/>I<suite> which has the "
257 "tip of each of the underlying suites as an ancestor, and which contains the "
258 "same as the suite which has the highest version of the package."
264 "The package must exist in mainsuite, but need not exist in the subsuites."
269 msgid "If a specified subsuite starts with B<-> then mainsuite is prepended."
275 "So, for example, B<stable,-security> means to look for the package in "
276 "stable, and stable-security, taking whichever is newer. If stable is "
277 "currently jessie, dgit clone would leave you on the branch B<dgit/jessie,-"
284 "Combined suites are not supported by the dgit build operations. This is "
285 "because those options are intended for building for uploading source "
286 "packages, and look in the changelog to find the relevant suite. It does not "
287 "make sense to name a dgit-synthesised combined suite in a changelog, or to "
288 "try to upload to it."
294 "When using this facility, it is important to always specify the same suites "
295 "in the same order: dgit will not be make a coherent fast-forwarding history "
302 "The history generated by this feature is not normally suitable for merging "
303 "back into upstreams, as it necessarily contains unattractive pseudomerges."
315 "Because the synthesis of the suite tracking branches is done locally based "
316 "only on the current archive state, it will not necessarily see every upload "
317 "not done with dgit. Also, different versions of dgit (or the software it "
318 "calls) might import the same .dscs differently (although we try to minimise "
319 "this). As a consequence, the dgit tracking views of the same suite, made by "
320 "different instances of dgit, may vary. They will have the same contents, "
321 "but may have different history."
327 "There is no uniform linkage between the tracking branches for different "
328 "suites. The Debian infrastructure does not do any automatic import of "
329 "uploads made without dgit. It would be possible for a distro's "
330 "infrastructure to do this; in that case, different dgit client instances "
331 "would see exactly the same history."
337 "There has been no bulk import of historical uploads into Debian's dgit "
338 "infrastructure. To do this it would be necessary to decide whether to "
339 "import existing vcs history (which might not be faithful to dgit's "
340 "invariants) or previous non-Dgit uploads (which would not provide a very "
347 "git represents only file executability. git does not represent empty "
348 "directories, or any leaf objects other than plain files and symlinks. The "
349 "behaviour of Debian source package formats on objects with unusual "
350 "permissions is complicated. Some pathological Debian source packages will "
351 "no longer build if empty directories are pruned (or if other things not "
352 "reproduced by git are changed). Such sources cannot be worked with properly "
353 "in git, and therefore not with dgit either."
359 msgid "READ-ONLY DISTROS"
365 "Distros which do not maintain a set of dgit history git repositories can "
366 "still be used in a read-only mode with dgit. Currently Ubuntu is configured "
373 msgid "GITATTRIBUTES"
379 "git has features which can automatically transform files as they are being "
380 "copied between the working tree and the git history. The attributes can be "
381 "specified in the source tree itself, in B<.gitattributes>. See "
382 "B<gitattributes>(5)."
388 "These transformations are context-sensitive and not, in general, reversible, "
389 "so dgit operates on the principle that the dgit git history contains the "
390 "actual contents of the package. (When dgit is manipulating a .dsc, it does "
391 "so in a private area, where the transforming gitattributes are defused, to "
398 "If transforming gitattributes are used, they can cause trouble, because the "
399 "working tree files can differ from the git revision history (and therefore "
400 "from the source packages). dgit warns if it finds a .gitattributes file (in "
401 "a package being fetched or imported), unless the transforming gitattributes "
408 "dgit clone and dgit setup-new-tree disable transforming gitattributes by "
409 "default, by creating a suitable .git/info/attributes. See B<dgit setup-new-"
410 "tree> and B<dgit setup-gitattributes> in dgit(1)."
416 "Note that dgit does not disable gitattributes unless they would actually "
417 "interfere with your work on dgit branches. In particular, gitattributes "
418 "which affect B<git archive> are not disabled, so .origs you generate by hand "
419 "can be wrong. You should consider using B<git-deborig (1)> which gets this "
420 "right, suppressing the attributes."
426 msgid "PACKAGE SOURCE FORMATS"
432 "If you are not the maintainer, you do not need to worry about the source "
433 "format of the package. You can just make changes as you like in git. If "
434 "the package is a `3.0 (quilt)' package, the patch stack will usually not be "
435 "represented in the git history."
441 msgid "FILE EXECUTABILITY"
447 "Debian source package formats do not always faithfully reproduce changes to "
448 "executability. But dgit insists that the result of dgit clone is identical "
449 "(as far as git can represent - see Limitations, above) to the result of "
456 "So files that are executable in your git tree must be executable in the "
457 "result of dpkg-source -x (but often aren't). If a package has such "
458 "troublesome files, they have to be non-executable in dgit-compatible git "
465 msgid "FORMAT 3.0 (QUILT)"
471 "For a format `3.0 (quilt)' source package, dgit may have to make a commit on "
472 "your current branch to contain metadata used by quilt and dpkg-source."
478 "This is because `3.0 (quilt)' source format represents the patch stack as "
479 "files in debian/patches/ actually inside the source tree. This means that, "
480 "taking the whole tree (as seen by git or ls) (i) dpkg-source cannot "
481 "represent certain trees, and (ii) packing up a tree in `3.0 (quilt)' and "
482 "then unpacking it does not always yield the same tree."
488 "dgit will automatically work around this for you when building and pushing. "
489 "The only thing you need to know is that dgit build, sbuild, etc., may make "
490 "new commits on your HEAD. If you're not a quilt user this commit won't "
491 "contain any changes to files you care about."
497 "Simply commiting to source files (whether in debian/ or not, but not to "
498 "patches) will result in a branch that dgit quilt-fixup can linearise. "
499 "Other kinds of changes, including editing patches or merging, cannot be "
506 "You can explicitly request that dgit do just this fixup, by running dgit "
513 "If you are a quilt user you need to know that dgit's git trees are `patches "
514 "applied packaging branches' and do not contain the .pc directory (which is "
515 "used by quilt to record which patches are applied). If you want to "
516 "manipulate the patch stack you probably want to be looking at tools like git-"
517 "debrebase, gbp pq, or git-dpm."
523 msgid "quilt fixup error messages"
528 msgid "When dgit's quilt fixup fails, it prints messages like this:"
535 "dgit: base trees orig=5531f03d8456b702eab6 o+d/p=135338e9cc253cc85f84\n"
536 "dgit: quilt differences: src: == orig ## gitignores: == orig ##\n"
537 "dgit: quilt differences: HEAD ## o+d/p HEAD ## o+d/p\n"
538 "starting quiltify (multiple patches, linear mode)\n"
545 "dgit: error: quilt fixup cannot be linear. Stopped at:\n"
546 "dgit: 696c9bd5..84ae8f96: changed debian/patches/test-gitignore\n"
558 "is an import of the .orig tarballs dgit found, with the debian/ directory "
559 "from your HEAD substituted. This is a git tree object, not a commit: you "
560 "can pass its hash to git-diff but not git-log."
572 "is another tree object, which is the same as orig but with the patches from "
573 "debian/patches applied."
584 msgid "is of course your own git HEAD."
590 msgid "B<quilt differences>"
596 "shows whether each of the these trees differs from the others (i) in "
597 "upstream files excluding .gitignore files; (ii) in upstream .gitignore "
598 "files. B<==> indicates equality; B<##> indicates inequality."
604 "dgit quilt-fixup --quilt=linear walks commits backwards from your HEAD "
605 "trying to construct a linear set of additional patches, starting at the "
606 "end. It hopes to eventually find an ancestor whose tree is identical to o+d/"
607 "p in all upstream files."
613 "In the error message, 696c9bd5..84ae8f96 is the first commit child-parent "
614 "edge which cannot be sensibly be either ignored, or turned into a patch in "
615 "debian/patches. In this example, this is because it itself changes files in "
616 "debian/patches, indicating that something unusual is going on and that "
617 "continuing is not safe. But you might also see other kinds of troublesome "
624 "Your appropriate response depends on the cause and the context. If you have "
625 "been freely merging your git branch and do not need need a pretty linear "
626 "patch queue, you can use B<--quilt=smash> (or use the B<1.0> or B<single-"
627 "debian-patch> source formats; see B<dpkg-source(1)>.) If you want a pretty "
628 "linear series, and this message is unexpected, it can mean that you have "
629 "unwittingly committed changes that are not representable by dpkg-source "
630 "(such as some mode changes). Or maybe you just forgot a necessary B<--"
637 "Finally, this problem can occur if you have provided Debian git tooling such "
638 "as git-debrebase, git-dpm or git-buildpackage with upstream git commit(s) or "
639 "tag(s) which are not 100% identical to your orig tarball(s)."
645 msgid "SPLIT VIEW QUILT MODE"
651 "When working with git branches intended for use with the `3.0 (quilt)' "
652 "source format dgit can automatically convert a suitable maintainer-provided "
653 "git branch (in one of a variety of formats) into a dgit branch."
659 "When a split view mode is engaged dgit build commands and dgit push will, on "
660 "each invocation, convert the user's HEAD into the dgit view, so that it can "
661 "be built and/or uploaded."
667 "dgit push in split view mode will push the dgit view to the dgit git "
668 "server. The dgit view is always a descendant of the maintainer view. dgit "
669 "push will also make a maintainer view tag according to DEP-14 and push that "
670 "to the dgit git server."
676 "Split view mode must be enabled explicitly (by the use of the applicable "
677 "command line options, subcommands, or configuration). This is because it is "
678 "not possible to reliably tell (for example) whether a git tree for a dpkg-"
679 "source `3.0 (quilt)' package is a patches-applied or patches-unapplied tree."
685 "Split view conversions are cached in the ref dgit-intern/quilt-cache. This "
686 "should not be manipulated directly."
692 msgid "FILES IN THE ORIG TARBALL BUT NOT IN GIT - AUTOTOOLS ETC."
698 "This section is mainly of interest to maintainers who want to use dgit with "
699 "their existing git history for the Debian package."
705 "Some developers like to have an extra-clean git tree which lacks files which "
706 "are normally found in source tarballs and therefore in Debian source "
707 "packages. For example, it is conventional to ship ./configure in the source "
708 "tarball, but some people prefer not to have it present in the git view of "
715 "dgit requires that the source package unpacks to exactly the same files as "
716 "are in the git commit on which dgit push operates. So if you just try to "
717 "dgit push directly from one of these extra-clean git branches, it will fail."
722 msgid "As the maintainer you therefore have the following options:"
726 #: ../dgit.7:445 ../dgit.7:456 ../dgit.7:505 ../dgit.7:513
734 "Delete the files from your git branches, and your Debian source packages, "
735 "and carry the deletion as a delta from upstream. (With `3.0 (quilt)' this "
736 "means represeting the deletions as patches. You may need to pass --include-"
737 "removal to dpkg-source --commit, or pass corresponding options to other "
738 "tools.) This can make the Debian source package less useful for people "
739 "without Debian build infrastructure."
745 "Persuade upstream that the source code in their git history and the source "
746 "they ship as tarballs should be identical. Of course simply removing the "
747 "files from the tarball may make the tarball hard for people to use."
753 "One answer is to commit the (maybe autogenerated) files, perhaps with some "
754 "simple automation to deal with conflicts and spurious changes. This has the "
755 "advantage that someone who clones the git repository finds the program just "
756 "as easy to build as someone who uses the tarball."
762 "Of course it may also be that the differences are due to build system bugs, "
763 "which cause unintended files to end up in the source package. dgit will "
764 "notice this and complain. You may have to fix these bugs before you can "
765 "unify your existing git history with dgit's."
771 msgid "FILES IN THE SOURCE PACKAGE BUT NOT IN GIT - DOCS, BINARIES ETC."
777 "Some upstream tarballs contain build artifacts which upstream expects some "
778 "users not to want to rebuild (or indeed to find hard to rebuild), but which "
779 "in Debian we always rebuild."
785 "Examples sometimes include crossbuild firmware binaries and documentation. "
786 "To avoid problems when building updated source packages (in particular, to "
787 "avoid trying to represent as changes in the source package uninteresting or "
788 "perhaps unrepresentable changes to such files) many maintainers arrange for "
789 "the package clean target to delete these files."
795 "dpkg-source does not (with any of the commonly used source formats) "
796 "represent deletion of binaries (outside debian/) present in upstream. Thus "
797 "deleting such files in a dpkg-source working tree does not actually result "
798 "in them being deleted from the source package. Thus deleting the files in "
799 "rules clean sweeps this problem under the rug."
805 "However, git does always properly record file deletion. Since dgit's "
806 "principle is that the dgit git tree is the same of dpkg-source -x, that "
807 "means that a dgit-compatible git tree always contains these files."
813 "For the non-maintainer, this can be observed in the following suboptimal "
820 "The package clean target often deletes these files, making the git tree "
821 "dirty trying to build the source package, etc. This can be fixed by using "
822 "B<dgit -wg> aka B<--clean=git>, so that the package clean target is never "
829 "The package build modifies these files, so that builds make the git tree "
830 "dirty. This can be worked around by using `git reset --hard' after each "
831 "build (or at least before each commit or push)."
837 "From the maintainer's point of view, the main consequence is that to make a "
838 "dgit-compatible git branch it is necessary to commit these files to git. "
839 "The maintainer has a few additional options for mitigation: for example, it "
840 "may be possible for the rules file to arrange to do the build in a temporary "
841 "area, which avoids updating the troublesome files; they can then be left in "
842 "the git tree without seeing trouble."
848 msgid "PROBLEMS WITH PACKAGE CLEAN TARGETS ETC."
854 "A related problem is other unexpected behaviour by a package's B<clean> "
855 "target. If a package's rules modify files which are distributed in the "
856 "package, or simply forget to remove certain files, dgit will complain that "
863 "Again, the solution is to use B<dgit -wg> aka B<--clean=git>, which "
864 "instructs dgit to use git clean instead of the package's build target, along "
865 "with perhaps B<git reset --hard> before each build."
871 "This is 100% reliable, but has the downside that if you forget to git add or "
872 "to commit, and then use B<dgit -wg> or B<git reset --hard>, your changes may "
~ianmdlvl / dgit.git / blob