Documentation / gitremote-helpers.txton commit wt-status.h: drop stdio.h include (7a06fb0)
   1gitremote-helpers(7)
   2====================
   3
   4NAME
   5----
   6gitremote-helpers - Helper programs to interact with remote repositories
   7
   8SYNOPSIS
   9--------
  10[verse]
  11'git remote-<transport>' <repository> [<URL>]
  12
  13DESCRIPTION
  14-----------
  15
  16Remote helper programs are normally not used directly by end users,
  17but they are invoked by Git when it needs to interact with remote
  18repositories Git does not support natively.  A given helper will
  19implement a subset of the capabilities documented here. When Git
  20needs to interact with a repository using a remote helper, it spawns
  21the helper as an independent process, sends commands to the helper's
  22standard input, and expects results from the helper's standard
  23output. Because a remote helper runs as an independent process from
  24Git, there is no need to re-link Git to add a new helper, nor any
  25need to link the helper with the implementation of Git.
  26
  27Every helper must support the "capabilities" command, which Git
  28uses to determine what other commands the helper will accept.  Those
  29other commands can be used to discover and update remote refs,
  30transport objects between the object database and the remote repository,
  31and update the local object store.
  32
  33Git comes with a "curl" family of remote helpers, that handle various
  34transport 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
  38INVOCATION
  39----------
  40
  41Remote helper programs are invoked with one or (optionally) two
  42arguments. The first argument specifies a remote repository as in Git;
  43it is either the name of a configured remote or a URL. The second
  44argument specifies a URL; it is usually of the form
  45'<transport>://<address>', but any arbitrary string is possible.
  46The `GIT_DIR` environment variable is set up for the remote helper
  47and can be used to determine where to store additional data or from
  48which directory to invoke auxiliary Git commands.
  49
  50When Git encounters a URL of the form '<transport>://<address>', where
  51'<transport>' is a protocol that it cannot handle natively, it
  52automatically invokes 'git remote-<transport>' with the full URL as
  53the second argument. If such a URL is encountered directly on the
  54command line, the first argument is the same as the second, and if it
  55is encountered in a configured remote, the first argument is the name
  56of that remote.
  57
  58A URL of the form '<transport>::<address>' explicitly instructs Git to
  59invoke 'git remote-<transport>' with '<address>' as the second
  60argument. If such a URL is encountered directly on the command line,
  61the first argument is '<address>', and if it is encountered in a
  62configured remote, the first argument is the name of that remote.
  63
  64Additionally, when a configured remote has `remote.<name>.vcs` set to
  65'<transport>', Git explicitly invokes 'git remote-<transport>' with
  66'<name>' as the first argument. If set, the second argument is
  67`remote.<name>.url`; otherwise, the second argument is omitted.
  68
  69INPUT FORMAT
  70------------
  71
  72Git sends the remote helper a list of commands on standard input, one
  73per line.  The first command is always the 'capabilities' command, in
  74response to which the remote helper must print a list of the
  75capabilities it supports (see below) followed by a blank line.  The
  76response to the capabilities command determines what commands Git uses
  77in the remainder of the command stream.
  78
  79The command stream is terminated by a blank line.  In some cases
  80(indicated in the documentation of the relevant commands), this blank
  81line is followed by a payload in some other protocol (e.g., the pack
  82protocol), while in others it indicates the end of input.
  83
  84Capabilities
  85~~~~~~~~~~~~
  86
  87Each remote helper is expected to support only a subset of commands.
  88The operations a helper supports are declared to Git in the response
  89to the `capabilities` command (see COMMANDS, below).
  90
  91In the following, we list all defined capabilities and for
  92each we list which commands a helper with that capability
  93must provide.
  94
  95Capabilities for Pushing
  96^^^^^^^^^^^^^^^^^^^^^^^^
  97'connect'::
  98        Can attempt to connect to 'git receive-pack' (for pushing),
  99        'git upload-pack', etc for communication using
 100        git's native packfile protocol. This
 101        requires a bidirectional, full-duplex connection.
 102+
 103Supported commands: 'connect'.
 104
 105'stateless-connect'::
 106        Experimental; for internal use only.
 107        Can attempt to connect to a remote server for communication
 108        using git's wire-protocol version 2.  See the documentation
 109        for the stateless-connect command for more information.
 110+
 111Supported commands: 'stateless-connect'.
 112
 113'push'::
 114        Can discover remote refs and push local commits and the
 115        history leading up to them to new or existing remote refs.
 116+
 117Supported commands: 'list for-push', 'push'.
 118
 119'export'::
 120        Can discover remote refs and push specified objects from a
 121        fast-import stream to remote refs.
 122+
 123Supported commands: 'list for-push', 'export'.
 124
 125If a helper advertises 'connect', Git will use it if possible and
 126fall back to another capability if the helper requests so when
 127connecting (see the 'connect' command under COMMANDS).
 128When choosing between 'push' and 'export', Git prefers 'push'.
 129Other frontends may have some other order of preference.
 130
 131'no-private-update'::
 132        When using the 'refspec' capability, git normally updates the
 133        private ref on successful push. This update is disabled when
 134        the remote-helper declares the capability 'no-private-update'.
 135
 136
 137Capabilities for Fetching
 138^^^^^^^^^^^^^^^^^^^^^^^^^
 139'connect'::
 140        Can try to connect to 'git upload-pack' (for fetching),
 141        'git receive-pack', etc for communication using the
 142        Git's native packfile protocol. This
 143        requires a bidirectional, full-duplex connection.
 144+
 145Supported commands: 'connect'.
 146
 147'stateless-connect'::
 148        Experimental; for internal use only.
 149        Can attempt to connect to a remote server for communication
 150        using git's wire-protocol version 2.  See the documentation
 151        for the stateless-connect command for more information.
 152+
 153Supported commands: 'stateless-connect'.
 154
 155'fetch'::
 156        Can discover remote refs and transfer objects reachable from
 157        them to the local object store.
 158+
 159Supported commands: 'list', 'fetch'.
 160
 161'import'::
 162        Can discover remote refs and output objects reachable from
 163        them as a stream in fast-import format.
 164+
 165Supported commands: 'list', 'import'.
 166
 167'check-connectivity'::
 168        Can guarantee that when a clone is requested, the received
 169        pack is self contained and is connected.
 170
 171If a helper advertises 'connect', Git will use it if possible and
 172fall back to another capability if the helper requests so when
 173connecting (see the 'connect' command under COMMANDS).
 174When choosing between 'fetch' and 'import', Git prefers 'fetch'.
 175Other frontends may have some other order of preference.
 176
 177Miscellaneous capabilities
 178^^^^^^^^^^^^^^^^^^^^^^^^^^
 179
 180'option'::
 181        For specifying settings like `verbosity` (how much output to
 182        write to stderr) and `depth` (how much history is wanted in the
 183        case of a shallow clone) that affect how other commands are
 184        carried out.
 185
 186'refspec' <refspec>::
 187        For remote helpers that implement 'import' or 'export', this capability
 188        allows the refs to be constrained to a private namespace, instead of
 189        writing to refs/heads or refs/remotes directly.
 190        It is recommended that all importers providing the 'import'
 191        capability use this. It's mandatory for 'export'.
 192+
 193A helper advertising the capability
 194`refspec refs/heads/*:refs/svn/origin/branches/*`
 195is saying that, when it is asked to `import refs/heads/topic`, the
 196stream it outputs will update the `refs/svn/origin/branches/topic`
 197ref.
 198+
 199This capability can be advertised multiple times.  The first
 200applicable refspec takes precedence.  The left-hand of refspecs
 201advertised with this capability must cover all refs reported by
 202the list command.  If no 'refspec' capability is advertised,
 203there is an implied `refspec *:*`.
 204+
 205When writing remote-helpers for decentralized version control
 206systems, it is advised to keep a local copy of the repository to
 207interact with, and to let the private namespace refs point to this
 208local repository, while the refs/remotes namespace is used to track
 209the remote repository.
 210
 211'bidi-import'::
 212        This modifies the 'import' capability.
 213        The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
 214        to retrieve information about blobs and trees that already exist in
 215        fast-import's memory. This requires a channel from fast-import to the
 216        remote-helper.
 217        If it is advertised in addition to "import", Git establishes a pipe from
 218        fast-import to the remote-helper's stdin.
 219        It follows that Git and fast-import are both connected to the
 220        remote-helper's stdin. Because Git can send multiple commands to
 221        the remote-helper it is required that helpers that use 'bidi-import'
 222        buffer all 'import' commands of a batch before sending data to fast-import.
 223        This is to prevent mixing commands and fast-import responses on the
 224        helper's stdin.
 225
 226'export-marks' <file>::
 227        This modifies the 'export' capability, instructing Git to dump the
 228        internal marks table to <file> when complete. For details,
 229        read up on `--export-marks=<file>` in linkgit:git-fast-export[1].
 230
 231'import-marks' <file>::
 232        This modifies the 'export' capability, instructing Git to load the
 233        marks specified in <file> before processing any input. For details,
 234        read up on `--import-marks=<file>` in linkgit:git-fast-export[1].
 235
 236'signed-tags'::
 237        This modifies the 'export' capability, instructing Git to pass
 238        `--signed-tags=verbatim` to linkgit:git-fast-export[1].  In the
 239        absence of this capability, Git will use `--signed-tags=warn-strip`.
 240
 241
 242
 243COMMANDS
 244--------
 245
 246Commands are given by the caller on the helper's standard input, one per line.
 247
 248'capabilities'::
 249        Lists the capabilities of the helper, one per line, ending
 250        with a blank line. Each capability may be preceded with '*',
 251        which marks them mandatory for Git versions using the remote
 252        helper to understand. Any unknown mandatory capability is a
 253        fatal error.
 254+
 255Support for this command is mandatory.
 256
 257'list'::
 258        Lists the refs, one per line, in the format "<value> <name>
 259        [<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for
 260        a symref, or "?" to indicate that the helper could not get the
 261        value of the ref. A space-separated list of attributes follows
 262        the name; unrecognized attributes are ignored. The list ends
 263        with a blank line.
 264+
 265See REF LIST ATTRIBUTES for a list of currently defined attributes.
 266+
 267Supported if the helper has the "fetch" or "import" capability.
 268
 269'list for-push'::
 270        Similar to 'list', except that it is used if and only if
 271        the caller wants to the resulting ref list to prepare
 272        push commands.
 273        A helper supporting both push and fetch can use this
 274        to distinguish for which operation the output of 'list'
 275        is going to be used, possibly reducing the amount
 276        of work that needs to be performed.
 277+
 278Supported if the helper has the "push" or "export" capability.
 279
 280'option' <name> <value>::
 281        Sets the transport helper option <name> to <value>.  Outputs a
 282        single line containing one of 'ok' (option successfully set),
 283        'unsupported' (option not recognized) or 'error <msg>'
 284        (option <name> is supported but <value> is not valid
 285        for it).  Options should be set before other commands,
 286        and may influence the behavior of those commands.
 287+
 288See OPTIONS for a list of currently defined options.
 289+
 290Supported if the helper has the "option" capability.
 291
 292'fetch' <sha1> <name>::
 293        Fetches the given object, writing the necessary objects
 294        to the database.  Fetch commands are sent in a batch, one
 295        per line, terminated with a blank line.
 296        Outputs a single blank line when all fetch commands in the
 297        same batch are complete. Only objects which were reported
 298        in the output of 'list' with a sha1 may be fetched this way.
 299+
 300Optionally may output a 'lock <file>' line indicating a file under
 301GIT_DIR/objects/pack which is keeping a pack until refs can be
 302suitably updated.
 303+
 304If option 'check-connectivity' is requested, the helper must output
 305'connectivity-ok' if the clone is self-contained and connected.
 306+
 307Supported if the helper has the "fetch" capability.
 308
 309'push' +<src>:<dst>::
 310        Pushes the given local <src> commit or branch to the
 311        remote branch described by <dst>.  A batch sequence of
 312        one or more 'push' commands is terminated with a blank line
 313        (if there is only one reference to push, a single 'push' command
 314        is followed by a blank line). For example, the following would
 315        be two batches of 'push', the first asking the remote-helper
 316        to push the local ref 'master' to the remote ref 'master' and
 317        the local `HEAD` to the remote 'branch', and the second
 318        asking to push ref 'foo' to ref 'bar' (forced update requested
 319        by the '+').
 320+
 321------------
 322push refs/heads/master:refs/heads/master
 323push HEAD:refs/heads/branch
 324\n
 325push +refs/heads/foo:refs/heads/bar
 326\n
 327------------
 328+
 329Zero or more protocol options may be entered after the last 'push'
 330command, before the batch's terminating blank line.
 331+
 332When the push is complete, outputs one or more 'ok <dst>' or
 333'error <dst> <why>?' lines to indicate success or failure of
 334each pushed ref.  The status report output is terminated by
 335a blank line.  The option field <why> may be quoted in a C
 336style string if it contains an LF.
 337+
 338Supported if the helper has the "push" capability.
 339
 340'import' <name>::
 341        Produces a fast-import stream which imports the current value
 342        of the named ref. It may additionally import other refs as
 343        needed to construct the history efficiently. The script writes
 344        to a helper-specific private namespace. The value of the named
 345        ref should be written to a location in this namespace derived
 346        by applying the refspecs from the "refspec" capability to the
 347        name of the ref.
 348+
 349Especially useful for interoperability with a foreign versioning
 350system.
 351+
 352Just like 'push', a batch sequence of one or more 'import' is
 353terminated with a blank line. For each batch of 'import', the remote
 354helper should produce a fast-import stream terminated by a 'done'
 355command.
 356+
 357Note that if the 'bidi-import' capability is used the complete batch
 358sequence has to be buffered before starting to send data to fast-import
 359to prevent mixing of commands and fast-import responses on the helper's
 360stdin.
 361+
 362Supported if the helper has the "import" capability.
 363
 364'export'::
 365        Instructs the remote helper that any subsequent input is
 366        part of a fast-import stream (generated by 'git fast-export')
 367        containing objects which should be pushed to the remote.
 368+
 369Especially useful for interoperability with a foreign versioning
 370system.
 371+
 372The 'export-marks' and 'import-marks' capabilities, if specified,
 373affect this command in so far as they are passed on to 'git
 374fast-export', which then will load/store a table of marks for
 375local objects. This can be used to implement for incremental
 376operations.
 377+
 378Supported if the helper has the "export" capability.
 379
 380'connect' <service>::
 381        Connects to given service. Standard input and standard output
 382        of helper are connected to specified service (git prefix is
 383        included in service name so e.g. fetching uses 'git-upload-pack'
 384        as service) on remote side. Valid replies to this command are
 385        empty line (connection established), 'fallback' (no smart
 386        transport support, fall back to dumb transports) and just
 387        exiting with error message printed (can't connect, don't
 388        bother trying to fall back). After line feed terminating the
 389        positive (empty) response, the output of service starts. After
 390        the connection ends, the remote helper exits.
 391+
 392Supported if the helper has the "connect" capability.
 393
 394'stateless-connect' <service>::
 395        Experimental; for internal use only.
 396        Connects to the given remote service for communication using
 397        git's wire-protocol version 2.  Valid replies to this command
 398        are empty line (connection established), 'fallback' (no smart
 399        transport support, fall back to dumb transports) and just
 400        exiting with error message printed (can't connect, don't bother
 401        trying to fall back).  After line feed terminating the positive
 402        (empty) response, the output of the service starts.  Messages
 403        (both request and response) must consist of zero or more
 404        PKT-LINEs, terminating in a flush packet. The client must not
 405        expect the server to store any state in between request-response
 406        pairs.  After the connection ends, the remote helper exits.
 407+
 408Supported if the helper has the "stateless-connect" capability.
 409
 410If a fatal error occurs, the program writes the error message to
 411stderr and exits. The caller should expect that a suitable error
 412message has been printed if the child closes the connection without
 413completing a valid response for the current command.
 414
 415Additional commands may be supported, as may be determined from
 416capabilities reported by the helper.
 417
 418REF LIST ATTRIBUTES
 419-------------------
 420
 421The 'list' command produces a list of refs in which each ref
 422may be followed by a list of attributes. The following ref list
 423attributes are defined.
 424
 425'unchanged'::
 426        This ref is unchanged since the last import or fetch, although
 427        the helper cannot necessarily determine what value that produced.
 428
 429OPTIONS
 430-------
 431
 432The following options are defined and (under suitable circumstances)
 433set by Git if the remote helper has the 'option' capability.
 434
 435'option verbosity' <n>::
 436        Changes the verbosity of messages displayed by the helper.
 437        A value of 0 for <n> means that processes operate
 438        quietly, and the helper produces only error output.
 439        1 is the default level of verbosity, and higher values
 440        of <n> correspond to the number of -v flags passed on the
 441        command line.
 442
 443'option progress' {'true'|'false'}::
 444        Enables (or disables) progress messages displayed by the
 445        transport helper during a command.
 446
 447'option depth' <depth>::
 448        Deepens the history of a shallow repository.
 449
 450'option deepen-since <timestamp>::
 451        Deepens the history of a shallow repository based on time.
 452
 453'option deepen-not <ref>::
 454        Deepens the history of a shallow repository excluding ref.
 455        Multiple options add up.
 456
 457'option deepen-relative {'true'|'false'}::
 458        Deepens the history of a shallow repository relative to
 459        current boundary. Only valid when used with "option depth".
 460
 461'option followtags' {'true'|'false'}::
 462        If enabled the helper should automatically fetch annotated
 463        tag objects if the object the tag points at was transferred
 464        during the fetch command.  If the tag is not fetched by
 465        the helper a second fetch command will usually be sent to
 466        ask for the tag specifically.  Some helpers may be able to
 467        use this option to avoid a second network connection.
 468
 469'option dry-run' {'true'|'false'}:
 470        If true, pretend the operation completed successfully,
 471        but don't actually change any repository data.  For most
 472        helpers this only applies to the 'push', if supported.
 473
 474'option servpath <c-style-quoted-path>'::
 475        Sets service path (--upload-pack, --receive-pack etc.) for
 476        next connect. Remote helper may support this option, but
 477        must not rely on this option being set before
 478        connect request occurs.
 479
 480'option check-connectivity' {'true'|'false'}::
 481        Request the helper to check connectivity of a clone.
 482
 483'option force' {'true'|'false'}::
 484        Request the helper to perform a force update.  Defaults to
 485        'false'.
 486
 487'option cloning' {'true'|'false'}::
 488        Notify the helper this is a clone request (i.e. the current
 489        repository is guaranteed empty).
 490
 491'option update-shallow' {'true'|'false'}::
 492        Allow to extend .git/shallow if the new refs require it.
 493
 494'option pushcert' {'true'|'false'}::
 495        GPG sign pushes.
 496
 497'option push-option <string>::
 498        Transmit <string> as a push option. As the push option
 499        must not contain LF or NUL characters, the string is not encoded.
 500
 501'option from-promisor' {'true'|'false'}::
 502        Indicate that these objects are being fetched from a promisor.
 503
 504'option no-dependents' {'true'|'false'}::
 505        Indicate that only the objects wanted need to be fetched, not
 506        their dependents.
 507
 508SEE ALSO
 509--------
 510linkgit:git-remote[1]
 511
 512linkgit:git-remote-ext[1]
 513
 514linkgit:git-remote-fd[1]
 515
 516linkgit:git-fast-import[1]
 517
 518GIT
 519---
 520Part of the linkgit:git[1] suite