]>
Commit | Line | Data |
---|---|---|
1 | git-remote-helpers(1) | |
2 | ===================== | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | git-remote-helpers - Helper programs to interact with remote repositories | |
7 | ||
8 | SYNOPSIS | |
9 | -------- | |
10 | [verse] | |
11 | 'git remote-<transport>' <repository> [<URL>] | |
12 | ||
13 | DESCRIPTION | |
14 | ----------- | |
15 | ||
16 | Remote helper programs are normally not used directly by end users, | |
17 | but they are invoked by git when it needs to interact with remote | |
18 | repositories git does not support natively. A given helper will | |
19 | implement a subset of the capabilities documented here. When git | |
20 | needs to interact with a repository using a remote helper, it spawns | |
21 | the helper as an independent process, sends commands to the helper's | |
22 | standard input, and expects results from the helper's standard | |
23 | output. Because a remote helper runs as an independent process from | |
24 | git, there is no need to re-link git to add a new helper, nor any | |
25 | need to link the helper with the implementation of git. | |
26 | ||
27 | Every helper must support the "capabilities" command, which git | |
28 | uses to determine what other commands the helper will accept. Those | |
29 | other commands can be used to discover and update remote refs, | |
30 | transport objects between the object database and the remote repository, | |
31 | and update the local object store. | |
32 | ||
33 | Git comes with a "curl" family of remote helpers, that handle various | |
34 | transport protocols, such as 'git-remote-http', 'git-remote-https', | |
35 | 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities | |
36 | 'fetch', 'option', and 'push'. | |
37 | ||
38 | INPUT FORMAT | |
39 | ------------ | |
40 | ||
41 | Git sends the remote helper a list of commands on standard input, one | |
42 | per line. The first command is always the 'capabilities' command, in | |
43 | response to which the remote helper must print a list of the | |
44 | capabilities it supports (see below) followed by a blank line. The | |
45 | response to the capabilities command determines what commands Git uses | |
46 | in the remainder of the command stream. | |
47 | ||
48 | The command stream is terminated by a blank line. In some cases | |
49 | (indicated in the documentation of the relevant commands), this blank | |
50 | line is followed by a payload in some other protocol (e.g., the pack | |
51 | protocol), while in others it indicates the end of input. | |
52 | ||
53 | Capabilities | |
54 | ~~~~~~~~~~~~ | |
55 | ||
56 | Each remote helper is expected to support only a subset of commands. | |
57 | The operations a helper supports are declared to git in the response | |
58 | to the `capabilities` command (see COMMANDS, below). | |
59 | ||
60 | 'option':: | |
61 | For specifying settings like `verbosity` (how much output to | |
62 | write to stderr) and `depth` (how much history is wanted in the | |
63 | case of a shallow clone) that affect how other commands are | |
64 | carried out. | |
65 | ||
66 | 'connect':: | |
67 | For fetching and pushing using git's native packfile protocol | |
68 | that requires a bidirectional, full-duplex connection. | |
69 | ||
70 | 'push':: | |
71 | For listing remote refs and pushing specified objects from the | |
72 | local object store to remote refs. | |
73 | ||
74 | 'fetch':: | |
75 | For listing remote refs and fetching the associated history to | |
76 | the local object store. | |
77 | ||
78 | 'import':: | |
79 | For listing remote refs and fetching the associated history as | |
80 | a fast-import stream. | |
81 | ||
82 | 'refspec' <refspec>:: | |
83 | This modifies the 'import' capability, allowing the produced | |
84 | fast-import stream to modify refs in a private namespace | |
85 | instead of writing to refs/heads or refs/remotes directly. | |
86 | It is recommended that all importers providing the 'import' | |
87 | capability use this. | |
88 | + | |
89 | A helper advertising the capability | |
90 | `refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}` | |
91 | is saying that, when it is asked to `import refs/heads/topic`, the | |
92 | stream it outputs will update the `refs/svn/origin/branches/topic` | |
93 | ref. | |
94 | + | |
95 | This capability can be advertised multiple times. The first | |
96 | applicable refspec takes precedence. The left-hand of refspecs | |
97 | advertised with this capability must cover all refs reported by | |
98 | the list command. If no 'refspec' capability is advertised, | |
99 | there is an implied `refspec {asterisk}:{asterisk}`. | |
100 | ||
101 | Capabilities for Pushing | |
102 | ~~~~~~~~~~~~~~~~~~~~~~~~ | |
103 | 'connect':: | |
104 | Can attempt to connect to 'git receive-pack' (for pushing), | |
105 | 'git upload-pack', etc for communication using the | |
106 | packfile protocol. | |
107 | + | |
108 | Supported commands: 'connect'. | |
109 | ||
110 | 'push':: | |
111 | Can discover remote refs and push local commits and the | |
112 | history leading up to them to new or existing remote refs. | |
113 | + | |
114 | Supported commands: 'list for-push', 'push'. | |
115 | ||
116 | If a helper advertises both 'connect' and 'push', git will use | |
117 | 'connect' if possible and fall back to 'push' if the helper requests | |
118 | so when connecting (see the 'connect' command under COMMANDS). | |
119 | ||
120 | Capabilities for Fetching | |
121 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
122 | 'connect':: | |
123 | Can try to connect to 'git upload-pack' (for fetching), | |
124 | 'git receive-pack', etc for communication using the | |
125 | packfile protocol. | |
126 | + | |
127 | Supported commands: 'connect'. | |
128 | ||
129 | 'fetch':: | |
130 | Can discover remote refs and transfer objects reachable from | |
131 | them to the local object store. | |
132 | + | |
133 | Supported commands: 'list', 'fetch'. | |
134 | ||
135 | 'import':: | |
136 | Can discover remote refs and output objects reachable from | |
137 | them as a stream in fast-import format. | |
138 | + | |
139 | Supported commands: 'list', 'import'. | |
140 | ||
141 | If a helper advertises 'connect', git will use it if possible and | |
142 | fall back to another capability if the helper requests so when | |
143 | connecting (see the 'connect' command under COMMANDS). | |
144 | When choosing between 'fetch' and 'import', git prefers 'fetch'. | |
145 | Other frontends may have some other order of preference. | |
146 | ||
147 | 'refspec' <refspec>:: | |
148 | This modifies the 'import' capability. | |
149 | + | |
150 | A helper advertising | |
151 | `refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}` | |
152 | in its capabilities is saying that, when it handles | |
153 | `import refs/heads/topic`, the stream it outputs will update the | |
154 | `refs/svn/origin/branches/topic` ref. | |
155 | + | |
156 | This capability can be advertised multiple times. The first | |
157 | applicable refspec takes precedence. The left-hand of refspecs | |
158 | advertised with this capability must cover all refs reported by | |
159 | the list command. If no 'refspec' capability is advertised, | |
160 | there is an implied `refspec {asterisk}:{asterisk}`. | |
161 | ||
162 | INVOCATION | |
163 | ---------- | |
164 | ||
165 | Remote helper programs are invoked with one or (optionally) two | |
166 | arguments. The first argument specifies a remote repository as in git; | |
167 | it is either the name of a configured remote or a URL. The second | |
168 | argument specifies a URL; it is usually of the form | |
169 | '<transport>://<address>', but any arbitrary string is possible. | |
170 | The 'GIT_DIR' environment variable is set up for the remote helper | |
171 | and can be used to determine where to store additional data or from | |
172 | which directory to invoke auxiliary git commands. | |
173 | ||
174 | When git encounters a URL of the form '<transport>://<address>', where | |
175 | '<transport>' is a protocol that it cannot handle natively, it | |
176 | automatically invokes 'git remote-<transport>' with the full URL as | |
177 | the second argument. If such a URL is encountered directly on the | |
178 | command line, the first argument is the same as the second, and if it | |
179 | is encountered in a configured remote, the first argument is the name | |
180 | of that remote. | |
181 | ||
182 | A URL of the form '<transport>::<address>' explicitly instructs git to | |
183 | invoke 'git remote-<transport>' with '<address>' as the second | |
184 | argument. If such a URL is encountered directly on the command line, | |
185 | the first argument is '<address>', and if it is encountered in a | |
186 | configured remote, the first argument is the name of that remote. | |
187 | ||
188 | Additionally, when a configured remote has 'remote.<name>.vcs' set to | |
189 | '<transport>', git explicitly invokes 'git remote-<transport>' with | |
190 | '<name>' as the first argument. If set, the second argument is | |
191 | 'remote.<name>.url'; otherwise, the second argument is omitted. | |
192 | ||
193 | COMMANDS | |
194 | -------- | |
195 | ||
196 | Commands are given by the caller on the helper's standard input, one per line. | |
197 | ||
198 | 'capabilities':: | |
199 | Lists the capabilities of the helper, one per line, ending | |
200 | with a blank line. Each capability may be preceded with '*', | |
201 | which marks them mandatory for git version using the remote | |
202 | helper to understand (unknown mandatory capability is fatal | |
203 | error). | |
204 | ||
205 | 'list':: | |
206 | Lists the refs, one per line, in the format "<value> <name> | |
207 | [<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for | |
208 | a symref, or "?" to indicate that the helper could not get the | |
209 | value of the ref. A space-separated list of attributes follows | |
210 | the name; unrecognized attributes are ignored. The list ends | |
211 | with a blank line. | |
212 | + | |
213 | If 'push' is supported this may be called as 'list for-push' | |
214 | to obtain the current refs prior to sending one or more 'push' | |
215 | commands to the helper. | |
216 | ||
217 | 'option' <name> <value>:: | |
218 | Sets the transport helper option <name> to <value>. Outputs a | |
219 | single line containing one of 'ok' (option successfully set), | |
220 | 'unsupported' (option not recognized) or 'error <msg>' | |
221 | (option <name> is supported but <value> is not valid | |
222 | for it). Options should be set before other commands, | |
223 | and may influence the behavior of those commands. | |
224 | + | |
225 | Supported if the helper has the "option" capability. | |
226 | ||
227 | 'fetch' <sha1> <name>:: | |
228 | Fetches the given object, writing the necessary objects | |
229 | to the database. Fetch commands are sent in a batch, one | |
230 | per line, terminated with a blank line. | |
231 | Outputs a single blank line when all fetch commands in the | |
232 | same batch are complete. Only objects which were reported | |
233 | in the ref list with a sha1 may be fetched this way. | |
234 | + | |
235 | Optionally may output a 'lock <file>' line indicating a file under | |
236 | GIT_DIR/objects/pack which is keeping a pack until refs can be | |
237 | suitably updated. | |
238 | + | |
239 | Supported if the helper has the "fetch" capability. | |
240 | ||
241 | 'push' +<src>:<dst>:: | |
242 | Pushes the given local <src> commit or branch to the | |
243 | remote branch described by <dst>. A batch sequence of | |
244 | one or more 'push' commands is terminated with a blank line | |
245 | (if there is only one reference to push, a single 'push' command | |
246 | is followed by a blank line). For example, the following would | |
247 | be two batches of 'push', the first asking the remote-helper | |
248 | to push the local ref 'master' to the remote ref 'master' and | |
249 | the local 'HEAD' to the remote 'branch', and the second | |
250 | asking to push ref 'foo' to ref 'bar' (forced update requested | |
251 | by the '+'). | |
252 | + | |
253 | ------------ | |
254 | push refs/heads/master:refs/heads/master | |
255 | push HEAD:refs/heads/branch | |
256 | \n | |
257 | push +refs/heads/foo:refs/heads/bar | |
258 | \n | |
259 | ------------ | |
260 | + | |
261 | Zero or more protocol options may be entered after the last 'push' | |
262 | command, before the batch's terminating blank line. | |
263 | + | |
264 | When the push is complete, outputs one or more 'ok <dst>' or | |
265 | 'error <dst> <why>?' lines to indicate success or failure of | |
266 | each pushed ref. The status report output is terminated by | |
267 | a blank line. The option field <why> may be quoted in a C | |
268 | style string if it contains an LF. | |
269 | + | |
270 | Supported if the helper has the "push" capability. | |
271 | ||
272 | 'import' <name>:: | |
273 | Produces a fast-import stream which imports the current value | |
274 | of the named ref. It may additionally import other refs as | |
275 | needed to construct the history efficiently. The script writes | |
276 | to a helper-specific private namespace. The value of the named | |
277 | ref should be written to a location in this namespace derived | |
278 | by applying the refspecs from the "refspec" capability to the | |
279 | name of the ref. | |
280 | + | |
281 | Especially useful for interoperability with a foreign versioning | |
282 | system. | |
283 | + | |
284 | Just like 'push', a batch sequence of one or more 'import' is | |
285 | terminated with a blank line. For each batch of 'import', the remote | |
286 | helper should produce a fast-import stream terminated by a 'done' | |
287 | command. | |
288 | + | |
289 | Supported if the helper has the "import" capability. | |
290 | ||
291 | 'connect' <service>:: | |
292 | Connects to given service. Standard input and standard output | |
293 | of helper are connected to specified service (git prefix is | |
294 | included in service name so e.g. fetching uses 'git-upload-pack' | |
295 | as service) on remote side. Valid replies to this command are | |
296 | empty line (connection established), 'fallback' (no smart | |
297 | transport support, fall back to dumb transports) and just | |
298 | exiting with error message printed (can't connect, don't | |
299 | bother trying to fall back). After line feed terminating the | |
300 | positive (empty) response, the output of service starts. After | |
301 | the connection ends, the remote helper exits. | |
302 | + | |
303 | Supported if the helper has the "connect" capability. | |
304 | ||
305 | If a fatal error occurs, the program writes the error message to | |
306 | stderr and exits. The caller should expect that a suitable error | |
307 | message has been printed if the child closes the connection without | |
308 | completing a valid response for the current command. | |
309 | ||
310 | Additional commands may be supported, as may be determined from | |
311 | capabilities reported by the helper. | |
312 | ||
313 | REF LIST ATTRIBUTES | |
314 | ------------------- | |
315 | ||
316 | 'for-push':: | |
317 | The caller wants to use the ref list to prepare push | |
318 | commands. A helper might chose to acquire the ref list by | |
319 | opening a different type of connection to the destination. | |
320 | ||
321 | 'unchanged':: | |
322 | This ref is unchanged since the last import or fetch, although | |
323 | the helper cannot necessarily determine what value that produced. | |
324 | ||
325 | OPTIONS | |
326 | ------- | |
327 | 'option verbosity' <n>:: | |
328 | Changes the verbosity of messages displayed by the helper. | |
329 | A value of 0 for <n> means that processes operate | |
330 | quietly, and the helper produces only error output. | |
331 | 1 is the default level of verbosity, and higher values | |
332 | of <n> correspond to the number of -v flags passed on the | |
333 | command line. | |
334 | ||
335 | 'option progress' \{'true'|'false'\}:: | |
336 | Enables (or disables) progress messages displayed by the | |
337 | transport helper during a command. | |
338 | ||
339 | 'option depth' <depth>:: | |
340 | Deepens the history of a shallow repository. | |
341 | ||
342 | 'option followtags' \{'true'|'false'\}:: | |
343 | If enabled the helper should automatically fetch annotated | |
344 | tag objects if the object the tag points at was transferred | |
345 | during the fetch command. If the tag is not fetched by | |
346 | the helper a second fetch command will usually be sent to | |
347 | ask for the tag specifically. Some helpers may be able to | |
348 | use this option to avoid a second network connection. | |
349 | ||
350 | 'option dry-run' \{'true'|'false'\}: | |
351 | If true, pretend the operation completed successfully, | |
352 | but don't actually change any repository data. For most | |
353 | helpers this only applies to the 'push', if supported. | |
354 | ||
355 | 'option servpath <c-style-quoted-path>':: | |
356 | Sets service path (--upload-pack, --receive-pack etc.) for | |
357 | next connect. Remote helper may support this option, but | |
358 | must not rely on this option being set before | |
359 | connect request occurs. | |
360 | ||
361 | SEE ALSO | |
362 | -------- | |
363 | linkgit:git-remote[1] | |
364 | ||
365 | GIT | |
366 | --- | |
367 | Part of the linkgit:git[1] suite |