dgit.1

   1 .TH dgit 1 "" "Debian Project" "dgit"
   2 .SH NAME
   3 dgit \- git integration with the Debian archive
   4 .
   5 .SH SYNOPSIS
   6 .B dgit
   7 [\fIdgit\-options\fP] \fBclone\fP [\fIdgit\-options\fP]
   8 \fIpackage\fP [\fIsuite\fP] [\fB./\fP\fIdest-dir|\fB/\fP\fIdest-dir]
   9 .br
  10 .B dgit
  11 [\fIdgit\-options\fP] \fBfetch\fP|\fBpull\fP [\fIdgit\-options\fP]
  12 [\fIsuite\fP]
  13 .br
  14 .B dgit
  15 [\fIdgit\-options\fP] \fBbuild\fP
  16 [\fIgit\-buildpackage\-options\fP|\fIdpkg\-buildpackage\-options\fp]
  17 .br
  18 .B dgit
  19 [\fIdgit\-options\fP] \fBpush\fP [\fIdgit\-options\fP]
  20 [\fIsuite\fP]
  21 .SH DESCRIPTION
  22 .B dgit
  23 treats the Debian archive as a version control system, and
  24 bidirectionally gateways between the archive and git.  The git view of
  25 the package can contain the usual upstream git history, and will be
  26 augmented by commits representing uploads done without using dgit.
  27 This git history is stored in a canonical location
  28 .B dgit-repos
  29 which lives outside the Debian archive.
  30
  31 .B dgit clone
  32 and
  33 .B dgit fetch
  34 consult the archive and dgit-repos and fetch and/or construct the
  35 git view of the history.  With clone, the destination directory (by
  36 default, the package name in the current directory) will be created.
  37
  38 .B dgit build
  39 runs
  40 .B git-buildpackage
  41 with some suitable options.  Options after
  42 .B build
  43 will be passed on to git-buildpackage.  It is not necessary to
  44 use dgit build; it is OK to use any approach which ensures that
  45 the generated source package corresponds to the relevant git commit.
  46 Tagging and signing should be left to dgit push.
  47
  48 .B dgit push
  49 does an `upload', pushing the current HEAD to the archive (as a source
  50 package) and to dgit-repos (as git commits).  This also involves
  51 making a signed git tag, and signing the files to be uploaded to the
  52 archive.
  53 .SH MODEL AND WORKFLOW
  54 You may use any suitable git workflow with dgit, provided you
  55 satisfy dgit's requirements:
  56
  57 The
  58 .B dgit-repos
  59 repository for each package contains one branch per suite named
  60 \fBdgit/\fR\fIsuite\fR.  These should be pushed to only by
  61 dgit.  They are fast forwarding.  Each push on this branch
  62 corresponds to an upload (or attempted upload).
  63
  64 dgit push can operate on any commit which is a descendant of the
  65 current dgit/suite tip in dgit-repos.
  66
  67 Uploads made by dgit contain an additional field
  68 .B Vcs-Git-Master
  69 in the source package .dsc.  (This is added by dgit push.)
  70 This specifies a commit (an ancestor of the dgit/suite
  71 branch) whose tree is identical to the unpacked source upload.
  72
  73 Uploads not made by dgit are represented in git by commits which are
  74 synthesised by dgit.  The tree of each such commit corresponds to the
  75 unpacked source; the single parent is the last known upload - that is,
  76 the contents of the dgit/suite branch.
  77
  78 dgit expects repos that it works with to have a
  79 .B dgit
  80 remote.  This refers to the well-known dgit-repos location
  81 (currently, the dgit-repos project on Alioth).  dgit fetch updates
  82 the remote tracking branch for dgit/suite.
  83 .SH OPTIONS
  84 .TP
  85 .BR --dry-run | -n
  86 Go through the motions, fetching all information needed, but do not
  87 actually update the output(s).  For fetch and pull, dgit determines
  88 which git commit corresponds to the archive but does not update
  89 remotes/dgit/dgit/suite or do any merge.  For push, dgit does
  90 the required checks and leaves the new .dsc in a temporary file,
  91 but does not sign, tag, push or upload.
  92 .TP
  93 .BI -k keyid
  94 Use
  95 .I keyid
  96 for signing the tag and the upload.
  97 .TP
  98 .BR --no-sign
  99 does not sign tags or uploads (meaningful only with push).
 100 .TP
 101 .BI -D
 102 Spew debugging information to stderr.
 103 .TP
 104 .BI -c name = value
 105 Specifies a git configuration option.  dgit itself is also controlled
 106 by git configuration options.
 107 .TP
 108 .RI \fB--dget=\fR program |\fB--dput=\fR program |\fB--debsign=\fR program
 109 Specifies alternative programs to use instead of dget, dput
 110 or debsign.
 111 .TP
 112 .RI \fB--dget:\fR option |\fB--dput:\fR option |\fB--debsign:\fR option
 113 Specifies a single additional option to pass to dget, dput or
 114 debsign.  Use repeatedly if multiple additional options are required.
 115 .TP
 116 .BI -C changesfile
 117 Specifies the .changes file which is to be uploaded.  By default
 118 dgit push looks for single .changes file in the parent directory whose
 119 filename suggests they it is for the right package and version.
 120 .SH BUGS
 121 dgit is not nearly configurable enough.  The locations for dgit-repos
 122 (on alioth) and for the Debian archive are currently hardcoded.
 123 There is not yet any support for suites which are in different
 124 distributions to Debian.
 125
 126 dgit will only work with packages in main. The madison http query API
 127 does not give the component.
 128
 129 dgit assumes knowledge of the archive layout.  There appears to be no
 130 sane way to find the path in the archive pool of the .dsc for a
 131 particular suite.
 132
 133 The mechanism for checking for and creating per-package repos on
 134 alioth is a hideous bodge.  One consequence is that dgit currently
 135 only works for people with push access.
 136
 137 Debian Maintainers are currently not able to push, as there is not
 138 currently any mechanism for determining and honouring the archive's
 139 ideas about access control.  Currently only DDs can push.
 140
 141 dgit's representation of format `3.0 (quilt)' source packages (even if
 142 they were supported) would not represent the patch stack.  Currently
 143 the patch series representation cannot round trip through the archive.
 144 Ideally dgit would represent a quilty package with an origin commit of
 145 some kind followed by the patch stack as a series of commits followed
 146 by a pseudo-merge (to make the branch fast-forwarding).  This would
 147 also mean a new `dgit rebase-prep' command or some such to turn such a
 148 fast-forwarding branch back into a rebasing patch stack, and a `force'
 149 option to dgit push (perhaps enabled automatically) which will make
 150 the required pseudo-merge.
 151
 152 dgit's handling of .orig.tar.gz is not very sophisticated.  Ideally
 153 the .orig.tar.gz could be transported via the git repo as git tags.
 154
 155 The error messages are often unhelpfully terse and tend to refer to
 156 line numbers in dgit.
 157
 158 The option parser requires values to be cuddled to the option name.