does an `upload', pushing the current HEAD to the archive (as a source
package) and to dgit-repos (as git commits). This also involves
making a signed git tag, and signing the files to be uploaded to the
-archive.
+archive. (For a format `3.0 (quilt)' source package, dgit push
+may also have to make a commit on your current branch to contain
+quilt metadata. It will do this automatically.)
+
+.B dgit quilt-fixup
+looks to see if there is quilt patch metadata left over by dpkg-source
+-b, and if so makes a git commit of it. This is normally done
+automatically by dgit push. dgit quilt-fixup takes no additional
+arguments. Note that it will only process a patch generated by
+dpkg-source for the most recent version (according to the
+debia/changelog).
.SH WORKFLOW - SIMPLE
It is always possible with dgit to clone or fetch a package, make
changes in git (using git-commit) on the suite branch
integrated the other relevant git history; if not you can fetch it
into your tree and cherry-pick etc. as you wish.
.SH WORKFLOW - INTEGRATING BETWEEN DGIT AND OTHER GIT HISTORY
-If you are the maintainer of a package, to deal with uploads made
+If you are the maintainer of a package dealing with uploads made
without dgit, you will probably want to merge the synthetic commits
(made by dgit to represent the uploads) into your git history.
Normally you can just merge the dgit branch into your own master, or
.BI dgit/ suite
you can just use dgit pull.
-However the first time you use dgit it will generate a new origin
+However the first time dgit is used it will generate a new origin
commit from the archive which won't be linked into the rest of your
git history. You will need to merge this.
-If last upload was made with git, you should usually proceed
+If last upload was in fact made with git, you should usually proceed
as follows: identify the commit which was actually used to build the
package. (Hopefully you have a tag for this.) Check out the dgit
branch
(or clone) obtain a git history representation of what's in the
archive and record it in the
.BI remotes/dgit/ suite
-tracking branch. Then construct somehow a git commit whose tree
-corresponds to the tree to use for the next upload. If that
-commit-to-be-uploaded is not a descendant of the dig tracking remote,
-check it out and say
-.RB ( "git merge -s ours debian/" \fIversion\fR).
-That tells git that we are intentionally throwing away any differences
+tracking branch. Then construct somehow, using your other git history
+plus appropriate diffs and cherry picks from the dgit remote tracking
+branch, a git commit whose tree corresponds to the tree to use for the
+next upload. If that commit-to-be-uploaded is not a descendant of the
+dig remote tracking branch, check it out and say
+.BR "git merge -s ours remotes/dgit/" \fIsuite\fR;
+that tells git that we are deliberately throwing away any differences
between what's in the archive and what you intend to upload.
Then run
.BR "dgit push"
If you are not the maintainer, you do not need to worry about the
source format of the package. You can just make changes as you like
in git. If the package is a `3.0 (quilt)' package, the patch stack
-will not (necessarily) be represented in the git history.
+will usually not be represented in the git history.
If you are the maintainer of a non-native package, you currently have
-two sensible options.
+two sensible options:
Firstly, you can regard your git history as primary, and the archive
as an export format. For example, you could maintain topic branches
Secondly, you can regard your quiltish patch stack in the archive as
primary. You will have to use other tools besides dgit to import and
-export this patch stack.
+export this patch stack. For `3.0 (quilt)' packages, dgit has to do
+more work to work around quilt braindamage. See also the BUGS
+section. We recommend against the use of `3.0 (quilt)'.
.SH OPTIONS
.TP
.BR --dry-run | -n
name of an existing package. Without --new we can just use the
package we are trying to push. But with --new that will not work, so
we guess that
-.B dpkg
-exists in the target suite. If it doesn't, you can use this option to
-specify a package which does. If the suite is empty, bad luck.
.SH CONFIGURATION
dgit looks at the following git config keys to control its behaviour.
You may set them with git-config (either in system-global or per-tree
.TP
.BI dgit.default.distro
.TP
-.BI dgit.default.username
+.BI dgit-distro. distro .username
.TP
.BI dgit-distro. distro .git-url
.TP
+.BI dgit-distro. distro .git-user
+.TP
.BI dgit-distro. distro .git-host
.TP
.BI dgit-distro. distro .git-proto
.TP
.BI dgit-distro. distro .archive-query-default-component
.TP
+.BI dgit-distro. distro .sshdakls-user
+.TP
+.BI dgit-distro. distro .sshdakls-host
+.TP
+.BI dgit-distro. distro .sshdakls-dir
+.TP
.BI dgit-distro. distro .ssh
.TP
.BR dgit.default. *
The method of canonicalising suite names is bizarre. See the
.B --existing-package
-option for one of the implication.s
+option for one of the implications.
dgit push should perhaps do `git push origin', or something similar,
by default.
+Debian does not have a working rmadison server, so to find out what
+version of a package is in the archive, or to canonicalise suite
+names, we ssh directly into the ftpmaster server.
+
The mechanism for checking for and creating per-package repos on
alioth is a hideous bodge. One consequence is that dgit currently
only works for people with push access.
Doing this is made more complicated by the possibility of a `3.0
(quilt)' package with multiple .orig tarballs.
+`3.0 (quilt)' packages have an additional difficulty: if these are
+edited in the most normal way, and then fed to dpkg-buildpackage,
+dpkg-source will add extra quilt patch metadata to the source tree
+during the source package build. This extra metadata is then of
+course not included in the git history. So dgit push needs to commit
+it for you, to make sure that the git history and archive contents are
+identical. That this is necessary is a bug in the `3.0 (quilt)'
+format.
+
The error messages are often unhelpfully terse and tend to refer to
line numbers in dgit.
~ianmdlvl / dgit.git / blobdiff