chiark / gitweb /
wip
[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
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 currently only works with Format 1.0 packages.
122
123 dgit is not nearly configurable enough.  The locations for dgit-repos
124 (on alioth) and for the Debian archive are currently hardcoded.
125 There is not yet any support for suites which are in different
126 distributions to Debian.
127
128 dgit will only work with packages in main. The madison http query API
129 does not give the component.
130
131 dgit assumes knowledge of the archive layout.  There appears to be no
132 sane way to find the path in the archive pool of the .dsc for a
133 particular suite.
134
135 The mechanism for checking for and creating per-package repos on
136 alioth is a hideous bodge.  One consequence is that dgit currently
137 only works for people with push access.
138
139 Debian Maintainers are currently not able to push, as there is not
140 currently any mechanism for determining and honouring the archive's
141 ideas about access control.  Currently only DDs can push.
142
143 dgit's representation of Format 3.0 (quilt) source packages (even if
144 they were supported) would not represent the patch stack.  Currently
145 the patch series representation cannot round trip through the archive.
146 Ideally dgit would represent a quilty package with an origin commit of
147 some kind followed by the patch stack as a series of commits followed
148 by a pseudo-merge (to make the branch fast-forwarding).  This would
149 also mean a new "dgit rebase-prep" command or some such to turn such a
150 fast-forwarding branch back into a rebasing patch stack, and a "force"
151 option to dgit push (perhaps enabled automatically) which will make
152 the required pseudo-merge.
153
154 dgit's handling of .orig.tar.gz is not very sophisticated.  Ideally
155 the .orig.tar.gz could be transported via the git repo as git tags.
156
157 The error messages are often unhelpfully terse and tend to refer to
158 line numbers in dgit.
159
160 The option parser requires values to be cuddled to the option name.