1GIT-PUSH(1) Git Manual GIT-PUSH(1)
2
6 git-push - Update remote refs along with associated objects
7
9 git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
10 [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
11 [-u | --set-upstream] [-o <string> | --push-option=<string>]
12 [--[no-]signed|--signed=(true|false|if-asked)]
13 [--force-with-lease[=<refname>[:<expect>]]]
14 [--no-verify] [<repository> [<refspec>...]]
15
18 Updates remote refs using local refs, while sending objects necessary
19 to complete the given refs.
20 You can make interesting things happen to a repository every time you
22 push into it, by setting up hooks there. See documentation for git-
23 receive-pack(1).
24 When the command line does not specify where to push with the
26 <repository> argument, branch.*.remote configuration for the current
27 branch is consulted to determine where to push. If the configuration is
28 missing, it defaults to origin.
29 When the command line does not specify what to push with <refspec>...
31 arguments or --all, --mirror, --tags options, the command finds the
32 default <refspec> by consulting remote.*.push configuration, and if it
33 is not found, honors push.default configuration to decide what to push
34 (See git-config(1) for the meaning of push.default).
35 When neither the command-line nor the configuration specify what to
37 push, the default behavior is used, which corresponds to the simple
38 value for push.default: the current branch is pushed to the
39 corresponding upstream branch, but as a safety measure, the push is
40 aborted if the upstream branch does not have the same name as the local
41 one.
42
44 <repository>
45 The "remote" repository that is destination of a push operation.
46 This parameter can be either a URL (see the section GIT URLS below)
47 or the name of a remote (see the section REMOTES below).
48 <refspec>...
50 Specify what destination ref to update with what source object. The
51 format of a <refspec> parameter is an optional plus +, followed by
52 the source object <src>, followed by a colon :, followed by the
53 destination ref <dst>.
54 The <src> is often the name of the branch you would want to push,
56 but it can be any arbitrary "SHA-1 expression", such as master~4 or
57 HEAD (see gitrevisions(7)).
58 The <dst> tells which ref on the remote side is updated with this
60 push. Arbitrary expressions cannot be used here, an actual ref must
61 be named. If git push [<repository>] without any <refspec> argument
62 is set to update some ref at the destination with <src> with
63 remote.<repository>.push configuration variable, :<dst> part can be
64 omitted—such a push will update a ref that <src> normally updates
65 without any <refspec> on the command line. Otherwise, missing
66 :<dst> means to update the same ref as the <src>.
67 The object referenced by <src> is used to update the <dst>
69 reference on the remote side. By default this is only allowed if
70 <dst> is not a tag (annotated or lightweight), and then only if it
71 can fast-forward <dst>. By having the optional leading +, you can
72 tell Git to update the <dst> ref even if it is not allowed by
73 default (e.g., it is not a fast-forward.) This does not attempt to
74 merge <src> into <dst>. See EXAMPLES below for details.
75 tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
77 Pushing an empty <src> allows you to delete the <dst> ref from the
79 remote repository.
80 The special refspec : (or +: to allow non-fast-forward updates)
82 directs Git to push "matching" branches: for every branch that
83 exists on the local side, the remote side is updated if a branch of
84 the same name already exists on the remote side.
85 --all
87 Push all branches (i.e. refs under refs/heads/); cannot be used
88 with other <refspec>.
89 --prune
91 Remove remote branches that don’t have a local counterpart. For
92 example a remote branch tmp will be removed if a local branch with
93 the same name doesn’t exist any more. This also respects refspecs,
94 e.g. git push --prune remote refs/heads/*:refs/tmp/* would make
95 sure that remote refs/tmp/foo will be removed if refs/heads/foo
96 doesn’t exist.
97 --mirror
99 Instead of naming each ref to push, specifies that all refs under
100 refs/ (which includes but is not limited to refs/heads/,
101 refs/remotes/, and refs/tags/) be mirrored to the remote
102 repository. Newly created local refs will be pushed to the remote
103 end, locally updated refs will be force updated on the remote end,
104 and deleted refs will be removed from the remote end. This is the
105 default if the configuration option remote.<remote>.mirror is set.
106 -n, --dry-run
108 Do everything except actually send the updates.
109 --porcelain
111 Produce machine-readable output. The output status line for each
112 ref will be tab-separated and sent to stdout instead of stderr. The
113 full symbolic names of the refs will be given.
114 -d, --delete
116 All listed refs are deleted from the remote repository. This is the
117 same as prefixing all refs with a colon.
118 --tags
120 All refs under refs/tags are pushed, in addition to refspecs
121 explicitly listed on the command line.
122 --follow-tags
124 Push all the refs that would be pushed without this option, and
125 also push annotated tags in refs/tags that are missing from the
126 remote but are pointing at commit-ish that are reachable from the
127 refs being pushed. This can also be specified with configuration
128 variable push.followTags. For more information, see push.followTags
129 in git-config(1).
130 --[no-]signed, --signed=(true|false|if-asked)
132 GPG-sign the push request to update refs on the receiving side, to
133 allow it to be checked by the hooks and/or be logged. If false or
134 --no-signed, no signing will be attempted. If true or --signed, the
135 push will fail if the server does not support signed pushes. If set
136 to if-asked, sign if and only if the server supports signed pushes.
137 The push will also fail if the actual call to gpg --sign fails. See
138 git-receive-pack(1) for the details on the receiving end.
139 --[no-]atomic
141 Use an atomic transaction on the remote side if available. Either
142 all refs are updated, or on error, no refs are updated. If the
143 server does not support atomic pushes the push will fail.
144 -o <option>, --push-option=<option>
146 Transmit the given string to the server, which passes them to the
147 pre-receive as well as the post-receive hook. The given string must
148 not contain a NUL or LF character. When multiple
149 --push-option=<option> are given, they are all sent to the other
150 side in the order listed on the command line. When no
151 --push-option=<option> is given from the command line, the values
152 of configuration variable push.pushOption are used instead.
153 --receive-pack=<git-receive-pack>, --exec=<git-receive-pack>
155 Path to the git-receive-pack program on the remote end. Sometimes
156 useful when pushing to a remote repository over ssh, and you do not
157 have the program in a directory on the default $PATH.
158 --[no-]force-with-lease, --force-with-lease=<refname>,
160 --force-with-lease=<refname>:<expect>
161 Usually, "git push" refuses to update a remote ref that is not an
162 ancestor of the local ref used to overwrite it.
163 This option overrides this restriction if the current value of the
165 remote ref is the expected value. "git push" fails otherwise.
166 Imagine that you have to rebase what you have already published.
168 You will have to bypass the "must fast-forward" rule in order to
169 replace the history you originally published with the rebased
170 history. If somebody else built on top of your original history
171 while you are rebasing, the tip of the branch at the remote may
172 advance with her commit, and blindly pushing with --force will lose
173 her work.
174 This option allows you to say that you expect the history you are
176 updating is what you rebased and want to replace. If the remote ref
177 still points at the commit you specified, you can be sure that no
178 other people did anything to the ref. It is like taking a "lease"
179 on the ref without explicitly locking it, and the remote ref is
180 updated only if the "lease" is still valid.
181 --force-with-lease alone, without specifying the details, will
183 protect all remote refs that are going to be updated by requiring
184 their current value to be the same as the remote-tracking branch we
185 have for them.
186 --force-with-lease=<refname>, without specifying the expected
188 value, will protect the named ref (alone), if it is going to be
189 updated, by requiring its current value to be the same as the
190 remote-tracking branch we have for it.
191 --force-with-lease=<refname>:<expect> will protect the named ref
193 (alone), if it is going to be updated, by requiring its current
194 value to be the same as the specified value <expect> (which is
195 allowed to be different from the remote-tracking branch we have for
196 the refname, or we do not even have to have such a remote-tracking
197 branch when this form is used). If <expect> is the empty string,
198 then the named ref must not already exist.
199 Note that all forms other than
201 --force-with-lease=<refname>:<expect> that specifies the expected
202 current value of the ref explicitly are still experimental and
203 their semantics may change as we gain experience with this feature.
204 "--no-force-with-lease" will cancel all the previous
206 --force-with-lease on the command line.
207 A general note on safety: supplying this option without an expected
209 value, i.e. as --force-with-lease or --force-with-lease=<refname>
210 interacts very badly with anything that implicitly runs git fetch
211 on the remote to be pushed to in the background, e.g. git fetch
212 origin on your repository in a cronjob.
213 The protection it offers over --force is ensuring that subsequent
215 changes your work wasn’t based on aren’t clobbered, but this is
216 trivially defeated if some background process is updating refs in
217 the background. We don’t have anything except the remote tracking
218 info to go by as a heuristic for refs you’re expected to have seen
219 & are willing to clobber.
220 If your editor or some other system is running git fetch in the
222 background for you a way to mitigate this is to simply set up
223 another remote:
224 git remote add origin-push $(git config remote.origin.url)
226 git fetch origin-push
227 Now when the background process runs git fetch origin the
229 references on origin-push won’t be updated, and thus commands like:
230 git push --force-with-lease origin-push
232 Will fail unless you manually run git fetch origin-push. This
234 method is of course entirely defeated by something that runs git
235 fetch --all, in that case you’d need to either disable it or do
236 something more tedious like:
237 git fetch # update 'master' from remote
239 git tag base master # mark our base point
240 git rebase -i master # rewrite some commits
241 git push --force-with-lease=master:base master:master
242 I.e. create a base tag for versions of the upstream code that
244 you’ve seen and are willing to overwrite, then rewrite history, and
245 finally force push changes to master if the remote version is still
246 at base, regardless of what your local remotes/origin/master has
247 been updated to in the background.
248 -f, --force
250 Usually, the command refuses to update a remote ref that is not an
251 ancestor of the local ref used to overwrite it. Also, when
252 --force-with-lease option is used, the command refuses to update a
253 remote ref whose current value does not match what is expected.
254 This flag disables these checks, and can cause the remote
256 repository to lose commits; use it with care.
257 Note that --force applies to all the refs that are pushed, hence
259 using it with push.default set to matching or with multiple push
260 destinations configured with remote.*.push may overwrite refs other
261 than the current branch (including local refs that are strictly
262 behind their remote counterpart). To force a push to only one
263 branch, use a + in front of the refspec to push (e.g git push
264 origin +master to force a push to the master branch). See the
265 <refspec>... section above for details.
266 --repo=<repository>
268 This option is equivalent to the <repository> argument. If both are
269 specified, the command-line argument takes precedence.
270 -u, --set-upstream
272 For every branch that is up to date or successfully pushed, add
273 upstream (tracking) reference, used by argument-less git-pull(1)
274 and other commands. For more information, see branch.<name>.merge
275 in git-config(1).
276 --[no-]thin
278 These options are passed to git-send-pack(1). A thin transfer
279 significantly reduces the amount of sent data when the sender and
280 receiver share many of the same objects in common. The default is
281 --thin.
282 -q, --quiet
284 Suppress all output, including the listing of updated refs, unless
285 an error occurs. Progress is not reported to the standard error
286 stream.
287 -v, --verbose
289 Run verbosely.
290 --progress
292 Progress status is reported on the standard error stream by default
293 when it is attached to a terminal, unless -q is specified. This
294 flag forces progress status even if the standard error stream is
295 not directed to a terminal.
296 --no-recurse-submodules, --recurse-submodules=check|on-demand|only|no
298 May be used to make sure all submodule commits used by the
299 revisions to be pushed are available on a remote-tracking branch.
300 If check is used Git will verify that all submodule commits that
301 changed in the revisions to be pushed are available on at least one
302 remote of the submodule. If any commits are missing the push will
303 be aborted and exit with non-zero status. If on-demand is used all
304 submodules that changed in the revisions to be pushed will be
305 pushed. If on-demand was not able to push all necessary revisions
306 it will also be aborted and exit with non-zero status. If only is
307 used all submodules will be recursively pushed while the
308 superproject is left unpushed. A value of no or using
309 --no-recurse-submodules can be used to override the
310 push.recurseSubmodules configuration variable when no submodule
311 recursion is required.
312 --[no-]verify
314 Toggle the pre-push hook (see githooks(5)). The default is
315 --verify, giving the hook a chance to prevent the push. With
316 --no-verify, the hook is bypassed completely.
317 -4, --ipv4
319 Use IPv4 addresses only, ignoring IPv6 addresses.
320 -6, --ipv6
322 Use IPv6 addresses only, ignoring IPv4 addresses.
323
325 In general, URLs contain information about the transport protocol, the
326 address of the remote server, and the path to the repository. Depending
327 on the transport protocol, some of this information may be absent.
328 Git supports ssh, git, http, and https protocols (in addition, ftp, and
330 ftps can be used for fetching, but this is inefficient and deprecated;
331 do not use it).
332 The native transport (i.e. git:// URL) does no authentication and
334 should be used with caution on unsecured networks.
335 The following syntaxes may be used with them:
337 · ssh://[user@]host.xz[:port]/path/to/repo.git/
339 · git://host.xz[:port]/path/to/repo.git/
341 · http[s]://host.xz[:port]/path/to/repo.git/
343 · ftp[s]://host.xz[:port]/path/to/repo.git/
345 An alternative scp-like syntax may also be used with the ssh protocol:
347 · [user@]host.xz:path/to/repo.git/
349 This syntax is only recognized if there are no slashes before the first
351 colon. This helps differentiate a local path that contains a colon. For
352 example the local path foo:bar could be specified as an absolute path
353 or ./foo:bar to avoid being misinterpreted as an ssh url.
354 The ssh and git protocols additionally support ~username expansion:
356 · ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
358 · git://host.xz[:port]/~[user]/path/to/repo.git/
360 · [user@]host.xz:/~[user]/path/to/repo.git/
362 For local repositories, also supported by Git natively, the following
364 syntaxes may be used:
365 · /path/to/repo.git/
367 · file:///path/to/repo.git/
369 These two syntaxes are mostly equivalent, except when cloning, when the
371 former implies --local option. See git-clone(1) for details.
372 When Git doesn’t know how to handle a certain transport protocol, it
374 attempts to use the remote-<transport> remote helper, if one exists. To
375 explicitly request a remote helper, the following syntax may be used:
376 · <transport>::<address>
378 where <address> may be a path, a server and path, or an arbitrary
380 URL-like string recognized by the specific remote helper being invoked.
381 See gitremote-helpers(1) for details.
382 If there are a large number of similarly-named remote repositories and
384 you want to use a different format for them (such that the URLs you use
385 will be rewritten into URLs that work), you can create a configuration
386 section of the form:
387 [url "<actual url base>"]
389 insteadOf = <other url base>
390 For example, with this:
393 [url "git://git.host.xz/"]
395 insteadOf = host.xz:/path/to/
396 insteadOf = work:
397 a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
400 rewritten in any context that takes a URL to be
401 "git://git.host.xz/repo.git".
402 If you want to rewrite URLs for push only, you can create a
404 configuration section of the form:
405 [url "<actual url base>"]
407 pushInsteadOf = <other url base>
408 For example, with this:
411 [url "ssh://example.org/"]
413 pushInsteadOf = git://example.org/
414 a URL like "git://example.org/path/to/repo.git" will be rewritten to
417 "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
418 use the original URL.
419
421 The name of one of the following can be used instead of a URL as
422 <repository> argument:
423 · a remote in the Git configuration file: $GIT_DIR/config,
425 · a file in the $GIT_DIR/remotes directory, or
427 · a file in the $GIT_DIR/branches directory.
429 All of these also allow you to omit the refspec from the command line
431 because they each contain a refspec which git will use by default.
432 Named remote in configuration file
434 You can choose to provide the name of a remote which you had previously
435 configured using git-remote(1), git-config(1) or even by a manual edit
436 to the $GIT_DIR/config file. The URL of this remote will be used to
437 access the repository. The refspec of this remote will be used by
438 default when you do not provide a refspec on the command line. The
439 entry in the config file would appear like this:
440 [remote "<name>"]
442 url = <url>
443 pushurl = <pushurl>
444 push = <refspec>
445 fetch = <refspec>
446 The <pushurl> is used for pushes only. It is optional and defaults to
449 <url>.
450 Named file in $GIT_DIR/remotes
452 You can choose to provide the name of a file in $GIT_DIR/remotes. The
453 URL in this file will be used to access the repository. The refspec in
454 this file will be used as default when you do not provide a refspec on
455 the command line. This file should have the following format:
456 URL: one of the above URL format
458 Push: <refspec>
459 Pull: <refspec>
460 Push: lines are used by git push and Pull: lines are used by git pull
463 and git fetch. Multiple Push: and Pull: lines may be specified for
464 additional branch mappings.
465 Named file in $GIT_DIR/branches
467 You can choose to provide the name of a file in $GIT_DIR/branches. The
468 URL in this file will be used to access the repository. This file
469 should have the following format:
470 <url>#<head>
472 <url> is required; #<head> is optional.
475 Depending on the operation, git will use one of the following refspecs,
477 if you don’t provide one on the command line. <branch> is the name of
478 this file in $GIT_DIR/branches and <head> defaults to master.
479 git fetch uses:
481 refs/heads/<head>:refs/heads/<branch>
483 git push uses:
486 HEAD:refs/heads/<head>
488
491 The output of "git push" depends on the transport method used; this
492 section describes the output when pushing over the Git protocol (either
493 locally or via ssh).
494 The status of the push is output in tabular form, with each line
496 representing the status of a single ref. Each line is of the form:
497 <flag> <summary> <from> -> <to> (<reason>)
499 If --porcelain is used, then each line of the output is of the form:
502 <flag> \t <from>:<to> \t <summary> (<reason>)
504 The status of up-to-date refs is shown only if --porcelain or --verbose
507 option is used.
508 flag
510 A single character indicating the status of the ref:
511 (space)
513 for a successfully pushed fast-forward;
514 +
516 for a successful forced update;
517 -
519 for a successfully deleted ref;
520 *
522 for a successfully pushed new ref;
523 !
525 for a ref that was rejected or failed to push; and
526 =
528 for a ref that was up to date and did not need pushing.
529 summary
531 For a successfully pushed ref, the summary shows the old and new
532 values of the ref in a form suitable for using as an argument to
533 git log (this is <old>..<new> in most cases, and <old>...<new> for
534 forced non-fast-forward updates).
535 For a failed update, more details are given:
537 rejected
539 Git did not try to send the ref at all, typically because it is
540 not a fast-forward and you did not force the update.
541 remote rejected
543 The remote end refused the update. Usually caused by a hook on
544 the remote side, or because the remote repository has one of
545 the following safety options in effect:
546 receive.denyCurrentBranch (for pushes to the checked out
547 branch), receive.denyNonFastForwards (for forced
548 non-fast-forward updates), receive.denyDeletes or
549 receive.denyDeleteCurrent. See git-config(1).
550 remote failure
552 The remote end did not report the successful update of the ref,
553 perhaps because of a temporary error on the remote side, a
554 break in the network connection, or other transient error.
555 from
557 The name of the local ref being pushed, minus its refs/<type>/
558 prefix. In the case of deletion, the name of the local ref is
559 omitted.
560 to
562 The name of the remote ref being updated, minus its refs/<type>/
563 prefix.
564 reason
566 A human-readable explanation. In the case of successfully pushed
567 refs, no explanation is needed. For a failed ref, the reason for
568 failure is described.
569
571 When an update changes a branch (or more in general, a ref) that used
572 to point at commit A to point at another commit B, it is called a
573 fast-forward update if and only if B is a descendant of A.
574 In a fast-forward update from A to B, the set of commits that the
576 original commit A built on top of is a subset of the commits the new
577 commit B builds on top of. Hence, it does not lose any history.
578 In contrast, a non-fast-forward update will lose history. For example,
580 suppose you and somebody else started at the same commit X, and you
581 built a history leading to commit B while the other person built a
582 history leading to commit A. The history looks like this:
583 B
585 /
586 ---X---A
587 Further suppose that the other person already pushed changes leading to
590 A back to the original repository from which you two obtained the
591 original commit X.
592 The push done by the other person updated the branch that used to point
594 at commit X to point at commit A. It is a fast-forward.
595 But if you try to push, you will attempt to update the branch (that now
597 points at A) with commit B. This does not fast-forward. If you did so,
598 the changes introduced by commit A will be lost, because everybody will
599 now start building on top of B.
600 The command by default does not allow an update that is not a
602 fast-forward to prevent such loss of history.
603 If you do not want to lose your work (history from X to B) or the work
605 by the other person (history from X to A), you would need to first
606 fetch the history from the repository, create a history that contains
607 changes done by both parties, and push the result back.
608 You can perform "git pull", resolve potential conflicts, and "git push"
610 the result. A "git pull" will create a merge commit C between commits A
611 and B.
612 B---C
614 / /
615 ---X---A
616 Updating A with the resulting merge commit will fast-forward and your
619 push will be accepted.
620 Alternatively, you can rebase your change between X and B on top of A,
622 with "git pull --rebase", and push the result back. The rebase will
623 create a new commit D that builds the change between X and B on top of
624 A.
625 B D
627 / /
628 ---X---A
629 Again, updating A with this commit will fast-forward and your push will
632 be accepted.
633 There is another common situation where you may encounter
635 non-fast-forward rejection when you try to push, and it is possible
636 even when you are pushing into a repository nobody else pushes into.
637 After you push commit A yourself (in the first picture in this
638 section), replace it with "git commit --amend" to produce commit B, and
639 you try to push it out, because forgot that you have pushed A out
640 already. In such a case, and only if you are certain that nobody in the
641 meantime fetched your earlier commit A (and started building on top of
642 it), you can run "git push --force" to overwrite it. In other words,
643 "git push --force" is a method reserved for a case where you do mean to
644 lose history.
645
647 git push
648 Works like git push <remote>, where <remote> is the current
649 branch’s remote (or origin, if no remote is configured for the
650 current branch).
651 git push origin
653 Without additional configuration, pushes the current branch to the
654 configured upstream (remote.origin.merge configuration variable) if
655 it has the same name as the current branch, and errors out without
656 pushing otherwise.
657 The default behavior of this command when no <refspec> is given can
659 be configured by setting the push option of the remote, or the
660 push.default configuration variable.
661 For example, to default to pushing only the current branch to
663 origin use git config remote.origin.push HEAD. Any valid <refspec>
664 (like the ones in the examples below) can be configured as the
665 default for git push origin.
666 git push origin :
668 Push "matching" branches to origin. See <refspec> in the OPTIONS
669 section above for a description of "matching" branches.
670 git push origin master
672 Find a ref that matches master in the source repository (most
673 likely, it would find refs/heads/master), and update the same ref
674 (e.g. refs/heads/master) in origin repository with it. If master
675 did not exist remotely, it would be created.
676 git push origin HEAD
678 A handy way to push the current branch to the same name on the
679 remote.
680 git push mothership master:satellite/master dev:satellite/dev
682 Use the source ref that matches master (e.g. refs/heads/master) to
683 update the ref that matches satellite/master (most probably
684 refs/remotes/satellite/master) in the mothership repository; do the
685 same for dev and satellite/dev.
686 This is to emulate git fetch run on the mothership using git push
688 that is run in the opposite direction in order to integrate the
689 work done on satellite, and is often necessary when you can only
690 make connection in one way (i.e. satellite can ssh into mothership
691 but mothership cannot initiate connection to satellite because the
692 latter is behind a firewall or does not run sshd).
693 After running this git push on the satellite machine, you would ssh
695 into the mothership and run git merge there to complete the
696 emulation of git pull that were run on mothership to pull changes
697 made on satellite.
698 git push origin HEAD:master
700 Push the current branch to the remote ref matching master in the
701 origin repository. This form is convenient to push the current
702 branch without thinking about its local name.
703 git push origin master:refs/heads/experimental
705 Create the branch experimental in the origin repository by copying
706 the current master branch. This form is only needed to create a new
707 branch or tag in the remote repository when the local name and the
708 remote name are different; otherwise, the ref name on its own will
709 work.
710 git push origin :experimental
712 Find a ref that matches experimental in the origin repository (e.g.
713 refs/heads/experimental), and delete it.
714 git push origin +dev:master
716 Update the origin repository’s master branch with the dev branch,
717 allowing non-fast-forward updates. This can leave unreferenced
718 commits dangling in the origin repository. Consider the following
719 situation, where a fast-forward is not possible:
720 o---o---o---A---B origin/master
722 \
723 X---Y---Z dev
724 The above command would change the origin repository to
726 A---B (unnamed branch)
728 /
729 o---o---o---X---Y---Z master
730 Commits A and B would no longer belong to a branch with a symbolic
732 name, and so would be unreachable. As such, these commits would be
733 removed by a git gc command on the origin repository.
734
736 The fetch and push protocols are not designed to prevent one side from
737 stealing data from the other repository that was not intended to be
738 shared. If you have private data that you need to protect from a
739 malicious peer, your best option is to store it in another repository.
740 This applies to both clients and servers. In particular, namespaces on
741 a server are not effective for read access control; you should only
742 grant read access to a namespace to clients that you would trust with
743 read access to the entire repository.
744 The known attack vectors are as follows:
746 1. The victim sends "have" lines advertising the IDs of objects it has
748 that are not explicitly intended to be shared but can be used to
749 optimize the transfer if the peer also has them. The attacker
750 chooses an object ID X to steal and sends a ref to X, but isn’t
751 required to send the content of X because the victim already has
752 it. Now the victim believes that the attacker has X, and it sends
753 the content of X back to the attacker later. (This attack is most
754 straightforward for a client to perform on a server, by creating a
755 ref to X in the namespace the client has access to and then
756 fetching it. The most likely way for a server to perform it on a
757 client is to "merge" X into a public branch and hope that the user
758 does additional work on this branch and pushes it back to the
759 server without noticing the merge.)
760 2. As in #1, the attacker chooses an object ID X to steal. The victim
762 sends an object Y that the attacker already has, and the attacker
763 falsely claims to have X and not Y, so the victim sends Y as a
764 delta against X. The delta reveals regions of X that are similar to
765 Y to the attacker.
766
768 Part of the git(1) suite
769Git 2.18.1 05/14/2019 GIT-PUSH(1)