You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
529 lines
20 KiB
529 lines
20 KiB
gitremote-helpers(7) |
|
==================== |
|
|
|
NAME |
|
---- |
|
gitremote-helpers - Helper programs to interact with remote repositories |
|
|
|
SYNOPSIS |
|
-------- |
|
[verse] |
|
'git remote-<transport>' <repository> [<URL>] |
|
|
|
DESCRIPTION |
|
----------- |
|
|
|
Remote helper programs are normally not used directly by end users, |
|
but they are invoked by Git when it needs to interact with remote |
|
repositories Git does not support natively. A given helper will |
|
implement a subset of the capabilities documented here. When Git |
|
needs to interact with a repository using a remote helper, it spawns |
|
the helper as an independent process, sends commands to the helper's |
|
standard input, and expects results from the helper's standard |
|
output. Because a remote helper runs as an independent process from |
|
Git, there is no need to re-link Git to add a new helper, nor any |
|
need to link the helper with the implementation of Git. |
|
|
|
Every helper must support the "capabilities" command, which Git |
|
uses to determine what other commands the helper will accept. Those |
|
other commands can be used to discover and update remote refs, |
|
transport objects between the object database and the remote repository, |
|
and update the local object store. |
|
|
|
Git comes with a "curl" family of remote helpers, that handle various |
|
transport protocols, such as 'git-remote-http', 'git-remote-https', |
|
'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities |
|
'fetch', 'option', and 'push'. |
|
|
|
INVOCATION |
|
---------- |
|
|
|
Remote helper programs are invoked with one or (optionally) two |
|
arguments. The first argument specifies a remote repository as in Git; |
|
it is either the name of a configured remote or a URL. The second |
|
argument specifies a URL; it is usually of the form |
|
'<transport>://<address>', but any arbitrary string is possible. |
|
The `GIT_DIR` environment variable is set up for the remote helper |
|
and can be used to determine where to store additional data or from |
|
which directory to invoke auxiliary Git commands. |
|
|
|
When Git encounters a URL of the form '<transport>://<address>', where |
|
'<transport>' is a protocol that it cannot handle natively, it |
|
automatically invokes 'git remote-<transport>' with the full URL as |
|
the second argument. If such a URL is encountered directly on the |
|
command line, the first argument is the same as the second, and if it |
|
is encountered in a configured remote, the first argument is the name |
|
of that remote. |
|
|
|
A URL of the form '<transport>::<address>' explicitly instructs Git to |
|
invoke 'git remote-<transport>' with '<address>' as the second |
|
argument. If such a URL is encountered directly on the command line, |
|
the first argument is '<address>', and if it is encountered in a |
|
configured remote, the first argument is the name of that remote. |
|
|
|
Additionally, when a configured remote has `remote.<name>.vcs` set to |
|
'<transport>', Git explicitly invokes 'git remote-<transport>' with |
|
'<name>' as the first argument. If set, the second argument is |
|
`remote.<name>.url`; otherwise, the second argument is omitted. |
|
|
|
INPUT FORMAT |
|
------------ |
|
|
|
Git sends the remote helper a list of commands on standard input, one |
|
per line. The first command is always the 'capabilities' command, in |
|
response to which the remote helper must print a list of the |
|
capabilities it supports (see below) followed by a blank line. The |
|
response to the capabilities command determines what commands Git uses |
|
in the remainder of the command stream. |
|
|
|
The command stream is terminated by a blank line. In some cases |
|
(indicated in the documentation of the relevant commands), this blank |
|
line is followed by a payload in some other protocol (e.g., the pack |
|
protocol), while in others it indicates the end of input. |
|
|
|
Capabilities |
|
~~~~~~~~~~~~ |
|
|
|
Each remote helper is expected to support only a subset of commands. |
|
The operations a helper supports are declared to Git in the response |
|
to the `capabilities` command (see COMMANDS, below). |
|
|
|
In the following, we list all defined capabilities and for |
|
each we list which commands a helper with that capability |
|
must provide. |
|
|
|
Capabilities for Pushing |
|
^^^^^^^^^^^^^^^^^^^^^^^^ |
|
'connect':: |
|
Can attempt to connect to 'git receive-pack' (for pushing), |
|
'git upload-pack', etc for communication using |
|
git's native packfile protocol. This |
|
requires a bidirectional, full-duplex connection. |
|
+ |
|
Supported commands: 'connect'. |
|
|
|
'stateless-connect':: |
|
Experimental; for internal use only. |
|
Can attempt to connect to a remote server for communication |
|
using git's wire-protocol version 2. See the documentation |
|
for the stateless-connect command for more information. |
|
+ |
|
Supported commands: 'stateless-connect'. |
|
|
|
'push':: |
|
Can discover remote refs and push local commits and the |
|
history leading up to them to new or existing remote refs. |
|
+ |
|
Supported commands: 'list for-push', 'push'. |
|
|
|
'export':: |
|
Can discover remote refs and push specified objects from a |
|
fast-import stream to remote refs. |
|
+ |
|
Supported commands: 'list for-push', 'export'. |
|
|
|
If a helper advertises 'connect', Git will use it if possible and |
|
fall back to another capability if the helper requests so when |
|
connecting (see the 'connect' command under COMMANDS). |
|
When choosing between 'push' and 'export', Git prefers 'push'. |
|
Other frontends may have some other order of preference. |
|
|
|
'no-private-update':: |
|
When using the 'refspec' capability, git normally updates the |
|
private ref on successful push. This update is disabled when |
|
the remote-helper declares the capability 'no-private-update'. |
|
|
|
|
|
Capabilities for Fetching |
|
^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
'connect':: |
|
Can try to connect to 'git upload-pack' (for fetching), |
|
'git receive-pack', etc for communication using the |
|
Git's native packfile protocol. This |
|
requires a bidirectional, full-duplex connection. |
|
+ |
|
Supported commands: 'connect'. |
|
|
|
'stateless-connect':: |
|
Experimental; for internal use only. |
|
Can attempt to connect to a remote server for communication |
|
using git's wire-protocol version 2. See the documentation |
|
for the stateless-connect command for more information. |
|
+ |
|
Supported commands: 'stateless-connect'. |
|
|
|
'fetch':: |
|
Can discover remote refs and transfer objects reachable from |
|
them to the local object store. |
|
+ |
|
Supported commands: 'list', 'fetch'. |
|
|
|
'import':: |
|
Can discover remote refs and output objects reachable from |
|
them as a stream in fast-import format. |
|
+ |
|
Supported commands: 'list', 'import'. |
|
|
|
'check-connectivity':: |
|
Can guarantee that when a clone is requested, the received |
|
pack is self contained and is connected. |
|
|
|
If a helper advertises 'connect', Git will use it if possible and |
|
fall back to another capability if the helper requests so when |
|
connecting (see the 'connect' command under COMMANDS). |
|
When choosing between 'fetch' and 'import', Git prefers 'fetch'. |
|
Other frontends may have some other order of preference. |
|
|
|
Miscellaneous capabilities |
|
^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
|
|
'option':: |
|
For specifying settings like `verbosity` (how much output to |
|
write to stderr) and `depth` (how much history is wanted in the |
|
case of a shallow clone) that affect how other commands are |
|
carried out. |
|
|
|
'refspec' <refspec>:: |
|
For remote helpers that implement 'import' or 'export', this capability |
|
allows the refs to be constrained to a private namespace, instead of |
|
writing to refs/heads or refs/remotes directly. |
|
It is recommended that all importers providing the 'import' |
|
capability use this. It's mandatory for 'export'. |
|
+ |
|
A helper advertising the capability |
|
`refspec refs/heads/*:refs/svn/origin/branches/*` |
|
is saying that, when it is asked to `import refs/heads/topic`, the |
|
stream it outputs will update the `refs/svn/origin/branches/topic` |
|
ref. |
|
+ |
|
This capability can be advertised multiple times. The first |
|
applicable refspec takes precedence. The left-hand of refspecs |
|
advertised with this capability must cover all refs reported by |
|
the list command. If no 'refspec' capability is advertised, |
|
there is an implied `refspec *:*`. |
|
+ |
|
When writing remote-helpers for decentralized version control |
|
systems, it is advised to keep a local copy of the repository to |
|
interact with, and to let the private namespace refs point to this |
|
local repository, while the refs/remotes namespace is used to track |
|
the remote repository. |
|
|
|
'bidi-import':: |
|
This modifies the 'import' capability. |
|
The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers |
|
to retrieve information about blobs and trees that already exist in |
|
fast-import's memory. This requires a channel from fast-import to the |
|
remote-helper. |
|
If it is advertised in addition to "import", Git establishes a pipe from |
|
fast-import to the remote-helper's stdin. |
|
It follows that Git and fast-import are both connected to the |
|
remote-helper's stdin. Because Git can send multiple commands to |
|
the remote-helper it is required that helpers that use 'bidi-import' |
|
buffer all 'import' commands of a batch before sending data to fast-import. |
|
This is to prevent mixing commands and fast-import responses on the |
|
helper's stdin. |
|
|
|
'export-marks' <file>:: |
|
This modifies the 'export' capability, instructing Git to dump the |
|
internal marks table to <file> when complete. For details, |
|
read up on `--export-marks=<file>` in linkgit:git-fast-export[1]. |
|
|
|
'import-marks' <file>:: |
|
This modifies the 'export' capability, instructing Git to load the |
|
marks specified in <file> before processing any input. For details, |
|
read up on `--import-marks=<file>` in linkgit:git-fast-export[1]. |
|
|
|
'signed-tags':: |
|
This modifies the 'export' capability, instructing Git to pass |
|
`--signed-tags=verbatim` to linkgit:git-fast-export[1]. In the |
|
absence of this capability, Git will use `--signed-tags=warn-strip`. |
|
|
|
|
|
|
|
COMMANDS |
|
-------- |
|
|
|
Commands are given by the caller on the helper's standard input, one per line. |
|
|
|
'capabilities':: |
|
Lists the capabilities of the helper, one per line, ending |
|
with a blank line. Each capability may be preceded with '*', |
|
which marks them mandatory for Git versions using the remote |
|
helper to understand. Any unknown mandatory capability is a |
|
fatal error. |
|
+ |
|
Support for this command is mandatory. |
|
|
|
'list':: |
|
Lists the refs, one per line, in the format "<value> <name> |
|
[<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for |
|
a symref, or "?" to indicate that the helper could not get the |
|
value of the ref. A space-separated list of attributes follows |
|
the name; unrecognized attributes are ignored. The list ends |
|
with a blank line. |
|
+ |
|
See REF LIST ATTRIBUTES for a list of currently defined attributes. |
|
+ |
|
Supported if the helper has the "fetch" or "import" capability. |
|
|
|
'list for-push':: |
|
Similar to 'list', except that it is used if and only if |
|
the caller wants to the resulting ref list to prepare |
|
push commands. |
|
A helper supporting both push and fetch can use this |
|
to distinguish for which operation the output of 'list' |
|
is going to be used, possibly reducing the amount |
|
of work that needs to be performed. |
|
+ |
|
Supported if the helper has the "push" or "export" capability. |
|
|
|
'option' <name> <value>:: |
|
Sets the transport helper option <name> to <value>. Outputs a |
|
single line containing one of 'ok' (option successfully set), |
|
'unsupported' (option not recognized) or 'error <msg>' |
|
(option <name> is supported but <value> is not valid |
|
for it). Options should be set before other commands, |
|
and may influence the behavior of those commands. |
|
+ |
|
See OPTIONS for a list of currently defined options. |
|
+ |
|
Supported if the helper has the "option" capability. |
|
|
|
'fetch' <sha1> <name>:: |
|
Fetches the given object, writing the necessary objects |
|
to the database. Fetch commands are sent in a batch, one |
|
per line, terminated with a blank line. |
|
Outputs a single blank line when all fetch commands in the |
|
same batch are complete. Only objects which were reported |
|
in the output of 'list' with a sha1 may be fetched this way. |
|
+ |
|
Optionally may output a 'lock <file>' line indicating the full path of |
|
a file under `$GIT_DIR/objects/pack` which is keeping a pack until |
|
refs can be suitably updated. The path must end with `.keep`. This is |
|
a mechanism to name a <pack,idx,keep> tuple by giving only the keep |
|
component. The kept pack will not be deleted by a concurrent repack, |
|
even though its objects may not be referenced until the fetch completes. |
|
The `.keep` file will be deleted at the conclusion of the fetch. |
|
+ |
|
If option 'check-connectivity' is requested, the helper must output |
|
'connectivity-ok' if the clone is self-contained and connected. |
|
+ |
|
Supported if the helper has the "fetch" capability. |
|
|
|
'push' +<src>:<dst>:: |
|
Pushes the given local <src> commit or branch to the |
|
remote branch described by <dst>. A batch sequence of |
|
one or more 'push' commands is terminated with a blank line |
|
(if there is only one reference to push, a single 'push' command |
|
is followed by a blank line). For example, the following would |
|
be two batches of 'push', the first asking the remote-helper |
|
to push the local ref 'master' to the remote ref 'master' and |
|
the local `HEAD` to the remote 'branch', and the second |
|
asking to push ref 'foo' to ref 'bar' (forced update requested |
|
by the '+'). |
|
+ |
|
------------ |
|
push refs/heads/master:refs/heads/master |
|
push HEAD:refs/heads/branch |
|
\n |
|
push +refs/heads/foo:refs/heads/bar |
|
\n |
|
------------ |
|
+ |
|
Zero or more protocol options may be entered after the last 'push' |
|
command, before the batch's terminating blank line. |
|
+ |
|
When the push is complete, outputs one or more 'ok <dst>' or |
|
'error <dst> <why>?' lines to indicate success or failure of |
|
each pushed ref. The status report output is terminated by |
|
a blank line. The option field <why> may be quoted in a C |
|
style string if it contains an LF. |
|
+ |
|
Supported if the helper has the "push" capability. |
|
|
|
'import' <name>:: |
|
Produces a fast-import stream which imports the current value |
|
of the named ref. It may additionally import other refs as |
|
needed to construct the history efficiently. The script writes |
|
to a helper-specific private namespace. The value of the named |
|
ref should be written to a location in this namespace derived |
|
by applying the refspecs from the "refspec" capability to the |
|
name of the ref. |
|
+ |
|
Especially useful for interoperability with a foreign versioning |
|
system. |
|
+ |
|
Just like 'push', a batch sequence of one or more 'import' is |
|
terminated with a blank line. For each batch of 'import', the remote |
|
helper should produce a fast-import stream terminated by a 'done' |
|
command. |
|
+ |
|
Note that if the 'bidi-import' capability is used the complete batch |
|
sequence has to be buffered before starting to send data to fast-import |
|
to prevent mixing of commands and fast-import responses on the helper's |
|
stdin. |
|
+ |
|
Supported if the helper has the "import" capability. |
|
|
|
'export':: |
|
Instructs the remote helper that any subsequent input is |
|
part of a fast-import stream (generated by 'git fast-export') |
|
containing objects which should be pushed to the remote. |
|
+ |
|
Especially useful for interoperability with a foreign versioning |
|
system. |
|
+ |
|
The 'export-marks' and 'import-marks' capabilities, if specified, |
|
affect this command in so far as they are passed on to 'git |
|
fast-export', which then will load/store a table of marks for |
|
local objects. This can be used to implement for incremental |
|
operations. |
|
+ |
|
Supported if the helper has the "export" capability. |
|
|
|
'connect' <service>:: |
|
Connects to given service. Standard input and standard output |
|
of helper are connected to specified service (git prefix is |
|
included in service name so e.g. fetching uses 'git-upload-pack' |
|
as service) on remote side. Valid replies to this command are |
|
empty line (connection established), 'fallback' (no smart |
|
transport support, fall back to dumb transports) and just |
|
exiting with error message printed (can't connect, don't |
|
bother trying to fall back). After line feed terminating the |
|
positive (empty) response, the output of service starts. After |
|
the connection ends, the remote helper exits. |
|
+ |
|
Supported if the helper has the "connect" capability. |
|
|
|
'stateless-connect' <service>:: |
|
Experimental; for internal use only. |
|
Connects to the given remote service for communication using |
|
git's wire-protocol version 2. Valid replies to this command |
|
are empty line (connection established), 'fallback' (no smart |
|
transport support, fall back to dumb transports) and just |
|
exiting with error message printed (can't connect, don't bother |
|
trying to fall back). After line feed terminating the positive |
|
(empty) response, the output of the service starts. Messages |
|
(both request and response) must consist of zero or more |
|
PKT-LINEs, terminating in a flush packet. The client must not |
|
expect the server to store any state in between request-response |
|
pairs. After the connection ends, the remote helper exits. |
|
+ |
|
Supported if the helper has the "stateless-connect" capability. |
|
|
|
If a fatal error occurs, the program writes the error message to |
|
stderr and exits. The caller should expect that a suitable error |
|
message has been printed if the child closes the connection without |
|
completing a valid response for the current command. |
|
|
|
Additional commands may be supported, as may be determined from |
|
capabilities reported by the helper. |
|
|
|
REF LIST ATTRIBUTES |
|
------------------- |
|
|
|
The 'list' command produces a list of refs in which each ref |
|
may be followed by a list of attributes. The following ref list |
|
attributes are defined. |
|
|
|
'unchanged':: |
|
This ref is unchanged since the last import or fetch, although |
|
the helper cannot necessarily determine what value that produced. |
|
|
|
OPTIONS |
|
------- |
|
|
|
The following options are defined and (under suitable circumstances) |
|
set by Git if the remote helper has the 'option' capability. |
|
|
|
'option verbosity' <n>:: |
|
Changes the verbosity of messages displayed by the helper. |
|
A value of 0 for <n> means that processes operate |
|
quietly, and the helper produces only error output. |
|
1 is the default level of verbosity, and higher values |
|
of <n> correspond to the number of -v flags passed on the |
|
command line. |
|
|
|
'option progress' {'true'|'false'}:: |
|
Enables (or disables) progress messages displayed by the |
|
transport helper during a command. |
|
|
|
'option depth' <depth>:: |
|
Deepens the history of a shallow repository. |
|
|
|
'option deepen-since <timestamp>:: |
|
Deepens the history of a shallow repository based on time. |
|
|
|
'option deepen-not <ref>:: |
|
Deepens the history of a shallow repository excluding ref. |
|
Multiple options add up. |
|
|
|
'option deepen-relative {'true'|'false'}:: |
|
Deepens the history of a shallow repository relative to |
|
current boundary. Only valid when used with "option depth". |
|
|
|
'option followtags' {'true'|'false'}:: |
|
If enabled the helper should automatically fetch annotated |
|
tag objects if the object the tag points at was transferred |
|
during the fetch command. If the tag is not fetched by |
|
the helper a second fetch command will usually be sent to |
|
ask for the tag specifically. Some helpers may be able to |
|
use this option to avoid a second network connection. |
|
|
|
'option dry-run' {'true'|'false'}: |
|
If true, pretend the operation completed successfully, |
|
but don't actually change any repository data. For most |
|
helpers this only applies to the 'push', if supported. |
|
|
|
'option servpath <c-style-quoted-path>':: |
|
Sets service path (--upload-pack, --receive-pack etc.) for |
|
next connect. Remote helper may support this option, but |
|
must not rely on this option being set before |
|
connect request occurs. |
|
|
|
'option check-connectivity' {'true'|'false'}:: |
|
Request the helper to check connectivity of a clone. |
|
|
|
'option force' {'true'|'false'}:: |
|
Request the helper to perform a force update. Defaults to |
|
'false'. |
|
|
|
'option cloning' {'true'|'false'}:: |
|
Notify the helper this is a clone request (i.e. the current |
|
repository is guaranteed empty). |
|
|
|
'option update-shallow' {'true'|'false'}:: |
|
Allow to extend .git/shallow if the new refs require it. |
|
|
|
'option pushcert' {'true'|'false'}:: |
|
GPG sign pushes. |
|
|
|
'option push-option <string>:: |
|
Transmit <string> as a push option. As the push option |
|
must not contain LF or NUL characters, the string is not encoded. |
|
|
|
'option from-promisor' {'true'|'false'}:: |
|
Indicate that these objects are being fetched from a promisor. |
|
|
|
'option no-dependents' {'true'|'false'}:: |
|
Indicate that only the objects wanted need to be fetched, not |
|
their dependents. |
|
|
|
'option atomic' {'true'|'false'}:: |
|
When pushing, request the remote server to update refs in a single atomic |
|
transaction. If successful, all refs will be updated, or none will. If the |
|
remote side does not support this capability, the push will fail. |
|
|
|
SEE ALSO |
|
-------- |
|
linkgit:git-remote[1] |
|
|
|
linkgit:git-remote-ext[1] |
|
|
|
linkgit:git-remote-fd[1] |
|
|
|
linkgit:git-fast-import[1] |
|
|
|
GIT |
|
--- |
|
Part of the linkgit:git[1] suite
|
|
|