chiark / gitweb /
archive-query config
[dgit.git] / 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 push, dgit does
99 the required checks and leaves the new .dsc in a temporary file,
100 but does not sign, tag, push or upload.
101 .TP
102 .BI -k keyid
103 Use
104 .I keyid
105 for signing the tag and the upload.
106 .TP
107 .BR --no-sign
108 does not sign tags or uploads (meaningful only with push).
109 .TP
110 .TP
111 .BI -p package
112 Specifies that we should process source package
113 .I package
114 rather than looking in debian/control.  Valid with dgit fetch
115 and dgit pull, only.
116 .TP
117 .BI -D
118 Spew debugging information to stderr.
119 .TP
120 .BI -c name = value
121 Specifies a git configuration option.  dgit itself is also controlled
122 by git configuration options.
123 .TP
124 .RI \fB--dget=\fR program |\fB--dput=\fR program |\fB--debsign=\fR program
125 Specifies alternative programs to use instead of dget, dput
126 or debsign.
127 .TP
128 .RI \fB--dget:\fR option |\fB--dput:\fR option |\fB--debsign:\fR option
129 Specifies a single additional option to pass to dget, dput or
130 debsign.  Use repeatedly if multiple additional options are required.
131 .TP
132 .BI -C changesfile
133 Specifies the .changes file which is to be uploaded.  By default
134 dgit push looks for single .changes file in the parent directory whose
135 filename suggests they it is for the right package and version.
136 .SH CONFIGURATION
137 dgit looks at the following git config keys to control its behaviour.
138 You may set them with git-config (either in system-global or per-tree
139 configuration), or provide
140 .BI -c key = value
141 on the dgit command line.
142 .TP
143 .BI dgit-suite. suite .distro
144 .TP
145 .BI dgit.default.distro
146 .TP
147 .BI dgit.default.username
148 .TP
149 .BI dgit-distro. distro .git-url
150 .TP
151 .BI dgit-distro. distro .git-host
152 .TP
153 .BI dgit-distro. distro .git-proto
154 .TP
155 .BI dgit-distro. distro .git-path
156 .TP
157 .BI dgit-distro. distro .git-check
158 .TP
159 .BI dgit-distro. distro .git-create
160 .TP
161 .BI dgit-distro. distro .upload-host
162 .TP
163 .BI dgit-distro. distro .mirror
164 .TP
165 .BI dgit-distro. distro .archive-query
166 .TP
167 .BI dgit-distro. distro .ssh
168 .TP
169 .BR dgit.default. *
170 for each
171 .BR dgit-distro. \fIdistro\fR . *
172 .SH BUGS
173 dgit will only work with packages in main. The madison http query API
174 does not give the component.
175
176 dgit assumes knowledge of the archive layout.  There appears to be no
177 sane way to find the path in the archive pool of the .dsc for a
178 particular suite.
179
180 Debian Policy needs to be updated to describe the new Vcs-Git-Master
181 field (and to specify that it is an RC bug for that field to refer
182 to an unavailable commit).
183
184 dgit push should perhaps do `git push origin', or something similar,
185 by default.
186
187 The mechanism for checking for and creating per-package repos on
188 alioth is a hideous bodge.  One consequence is that dgit currently
189 only works for people with push access.
190
191 Debian Maintainers are currently not able to push, as there is not
192 currently any mechanism for determining and honouring the archive's
193 ideas about access control.  Currently only DDs can push.
194
195 dgit's representation of format `3.0 (quilt)' source packages (even if
196 they were supported) would not represent the patch stack.  Currently
197 the patch series representation cannot round trip through the archive.
198 Ideally dgit would represent a quilty package with an origin commit of
199 some kind followed by the patch stack as a series of commits followed
200 by a pseudo-merge (to make the branch fast-forwarding).  This would
201 also mean a new `dgit rebase-prep' command or some such to turn such a
202 fast-forwarding branch back into a rebasing patch stack, and a `force'
203 option to dgit push (perhaps enabled automatically) which will make
204 the required pseudo-merge.
205
206 dgit's handling of .orig.tar.gz is not very sophisticated.  Ideally
207 the .orig.tar.gz could be transported via the git repo as git tags.
208
209 The error messages are often unhelpfully terse and tend to refer to
210 line numbers in dgit.
211
212 The option parser requires values to be cuddled to the option name.
213
214 --dry-run often does not work with fetch, even though this is a
215 logically plausible request.  (It fails, instead.)