| 1 | git-upload-pack(1) |
| 2 | ================== |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | git-upload-pack - Send objects packed back to git-fetch-pack |
| 7 | |
| 8 | |
| 9 | SYNOPSIS |
| 10 | -------- |
| 11 | [verse] |
| 12 | 'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc] |
| 13 | [--advertise-refs] <directory> |
| 14 | |
| 15 | DESCRIPTION |
| 16 | ----------- |
| 17 | Invoked by 'git fetch-pack', learns what |
| 18 | objects the other side is missing, and sends them after packing. |
| 19 | |
| 20 | This command is usually not invoked directly by the end user. |
| 21 | The UI for the protocol is on the 'git fetch-pack' side, and the |
| 22 | program pair is meant to be used to pull updates from a remote |
| 23 | repository. For push operations, see 'git send-pack'. |
| 24 | |
| 25 | OPTIONS |
| 26 | ------- |
| 27 | |
| 28 | --strict:: |
| 29 | --no-strict:: |
| 30 | Do not try <directory>/.git/ if <directory> is not a Git directory. |
| 31 | |
| 32 | --timeout=<n>:: |
| 33 | Interrupt transfer after <n> seconds of inactivity. |
| 34 | |
| 35 | --stateless-rpc:: |
| 36 | Perform only a single read-write cycle with stdin and stdout. |
| 37 | This fits with the HTTP POST request processing model where |
| 38 | a program may read the request, write a response, and must exit. |
| 39 | |
| 40 | --http-backend-info-refs:: |
| 41 | Used by linkgit:git-http-backend[1] to serve up |
| 42 | `$GIT_URL/info/refs?service=git-upload-pack` requests. See |
| 43 | "Smart Clients" in linkgit:gitprotocol-http[5] and "HTTP |
| 44 | Transport" in the linkgit:gitprotocol-v2[5] |
| 45 | documentation. Also understood by |
| 46 | linkgit:git-receive-pack[1]. |
| 47 | |
| 48 | <directory>:: |
| 49 | The repository to sync from. |
| 50 | |
| 51 | ENVIRONMENT |
| 52 | ----------- |
| 53 | |
| 54 | `GIT_PROTOCOL`:: |
| 55 | Internal variable used for handshaking the wire protocol. Server |
| 56 | admins may need to configure some transports to allow this |
| 57 | variable to be passed. See the discussion in linkgit:git[1]. |
| 58 | |
| 59 | `GIT_NO_LAZY_FETCH`:: |
| 60 | When cloning or fetching from a partial repository (i.e., one |
| 61 | itself cloned with `--filter`), the server-side `upload-pack` |
| 62 | may need to fetch extra objects from its upstream in order to |
| 63 | complete the request. By default, `upload-pack` will refuse to |
| 64 | perform such a lazy fetch, because `git fetch` may run arbitrary |
| 65 | commands specified in configuration and hooks of the source |
| 66 | repository (and `upload-pack` tries to be safe to run even in |
| 67 | untrusted `.git` directories). |
| 68 | + |
| 69 | This is implemented by having `upload-pack` internally set the |
| 70 | `GIT_NO_LAZY_FETCH` variable to `1`. If you want to override it |
| 71 | (because you are fetching from a partial clone, and you are sure |
| 72 | you trust it), you can explicitly set `GIT_NO_LAZY_FETCH` to |
| 73 | `0`. |
| 74 | |
| 75 | SECURITY |
| 76 | -------- |
| 77 | |
| 78 | Most Git commands should not be run in an untrusted `.git` directory |
| 79 | (see the section `SECURITY` in linkgit:git[1]). `upload-pack` tries to |
| 80 | avoid any dangerous configuration options or hooks from the repository |
| 81 | it's serving, making it safe to clone an untrusted directory and run |
| 82 | commands on the resulting clone. |
| 83 | |
| 84 | For an extra level of safety, you may be able to run `upload-pack` as an |
| 85 | alternate user. The details will be platform dependent, but on many |
| 86 | systems you can run: |
| 87 | |
| 88 | git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ... |
| 89 | |
| 90 | SEE ALSO |
| 91 | -------- |
| 92 | linkgit:gitnamespaces[7] |
| 93 | |
| 94 | GIT |
| 95 | --- |
| 96 | Part of the linkgit:git[1] suite |