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 and the new directory's `origin' remote will be set up to point to
  38 the package's dgit-repos tree.
  39
  40 .B dgit build
  41 runs
  42 .B git-buildpackage
  43 with some suitable options.  Options after
  44 .B build
  45 will be passed on to git-buildpackage.  It is not necessary to
  46 use dgit build; it is OK to use any approach which ensures that
  47 the generated source package corresponds to the relevant git commit.
  48 Tagging and signing should be left to dgit push.
  49
  50 .B dgit push
  51 does an `upload', pushing the current HEAD to the archive (as a source
  52 package) and to dgit-repos (as git commits).  This also involves
  53 making a signed git tag, and signing the files to be uploaded to the
  54 archive.
  55 .SH MODEL AND WORKFLOW
  56 You may use any suitable git workflow with dgit, provided you
  57 satisfy dgit's requirements:
  58
  59 dgit maintains what looks a bit like a remote called
  60 .BR dgit ,
  61 with one branch per suite.  This remote cannot be used with
  62 plain git.
  63
  64 The
  65 .B dgit-repos
  66 repository for each package contains one ref per suite named
  67 \fBdrefs/git/\fR\fIsuite\fR.  These should be pushed to only by
  68 dgit.  They are fast forwarding.  Each push on this branch
  69 corresponds to an upload (or attempted upload).
  70
  71 However, it is perfectly fine to have other branches in dgit-repos;
  72 normally the dgit-repos repo for the package will be accessible via
  73 the remote name `origin'.
  74
  75 dgit push can operate on any commit which is a descendant of the
  76 current dgit/suite tip in dgit-repos.
  77
  78 Uploads made by dgit contain an additional field
  79 .B Vcs-Git-Master
  80 in the source package .dsc.  (This is added by dgit push.)
  81 This specifies a commit (an ancestor of the dgit/suite
  82 branch) whose tree is identical to the unpacked source upload.
  83
  84 Uploads not made by dgit are represented in git by commits which are
  85 synthesised by dgit.  The tree of each such commit corresponds to the
  86 unpacked source; the single parent is the last known upload - that is,
  87 the contents of the dgit/suite branch.
  88
  89 dgit expects repos that it works with to have a
  90 .B dgit
  91 remote.  This refers to the well-known dgit-repos location
  92 (currently, the dgit-repos project on Alioth).  dgit fetch updates
  93 the remote tracking branch for dgit/suite.
  94 .SH OPTIONS
  95 .TP
  96 .BR --dry-run | -n
  97 Go through the motions, fetching all information needed, but do not
  98 actually update the output(s).  For fetch and pull, dgit determines
  99 which git commit corresponds to the archive but does not update
 100 remotes/dgit/dgit/suite or do any merge.  For push, dgit does
 101 the required checks and leaves the new .dsc in a temporary file,
 102 but does not sign, tag, push or upload.
 103 .TP
 104 .BI -k keyid
 105 Use
 106 .I keyid
 107 for signing the tag and the upload.
 108 .TP
 109 .BR --no-sign
 110 does not sign tags or uploads (meaningful only with push).
 111 .TP
 112 .BI -D
 113 Spew debugging information to stderr.
 114 .TP
 115 .BI -c name = value
 116 Specifies a git configuration option.  dgit itself is also controlled
 117 by git configuration options.
 118 .TP
 119 .RI \fB--dget=\fR program |\fB--dput=\fR program |\fB--debsign=\fR program
 120 Specifies alternative programs to use instead of dget, dput
 121 or debsign.
 122 .TP
 123 .RI \fB--dget:\fR option |\fB--dput:\fR option |\fB--debsign:\fR option
 124 Specifies a single additional option to pass to dget, dput or
 125 debsign.  Use repeatedly if multiple additional options are required.
 126 .TP
 127 .BI -C changesfile
 128 Specifies the .changes file which is to be uploaded.  By default
 129 dgit push looks for single .changes file in the parent directory whose
 130 filename suggests they it is for the right package and version.
 131 .SH BUGS
 132 dgit is not nearly configurable enough.  The locations for dgit-repos
 133 (on alioth) and for the Debian archive are currently hardcoded.
 134 There is not yet any support for suites which are in different
 135 distributions to Debian.
 136
 137 dgit will only work with packages in main. The madison http query API
 138 does not give the component.
 139
 140 dgit assumes knowledge of the archive layout.  There appears to be no
 141 sane way to find the path in the archive pool of the .dsc for a
 142 particular suite.
 143
 144 The mechanism for checking for and creating per-package repos on
 145 alioth is a hideous bodge.  One consequence is that dgit currently
 146 only works for people with push access.
 147
 148 Debian Maintainers are currently not able to push, as there is not
 149 currently any mechanism for determining and honouring the archive's
 150 ideas about access control.  Currently only DDs can push.
 151
 152 dgit's representation of format `3.0 (quilt)' source packages (even if
 153 they were supported) would not represent the patch stack.  Currently
 154 the patch series representation cannot round trip through the archive.
 155 Ideally dgit would represent a quilty package with an origin commit of
 156 some kind followed by the patch stack as a series of commits followed
 157 by a pseudo-merge (to make the branch fast-forwarding).  This would
 158 also mean a new `dgit rebase-prep' command or some such to turn such a
 159 fast-forwarding branch back into a rebasing patch stack, and a `force'
 160 option to dgit push (perhaps enabled automatically) which will make
 161 the required pseudo-merge.
 162
 163 dgit's handling of .orig.tar.gz is not very sophisticated.  Ideally
 164 the .orig.tar.gz could be transported via the git repo as git tags.
 165
 166 The error messages are often unhelpfully terse and tend to refer to
 167 line numbers in dgit.
 168
 169 The option parser requires values to be cuddled to the option name.