SYNOPSIS
--------
[verse]
-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
- [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
+'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+ [--repo=all] [-f | --force] [-v | --verbose]
+ [<repository> <refspec>...]
DESCRIPTION
-----------
The "remote" repository that is destination of a push
operation. See the section <<URLS,GIT URLS>> below.
-<refspec>::
+<refspec>...::
- The canonical format of each <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `+`, followed
+ The canonical format of a <refspec> parameter is
+ `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
--mirror::
Instead of naming each ref to push, specifies that all
- refs under `$GIT_DIR/refs/heads/` and `$GIT_DIR/refs/tags/`
+ refs under `$GIT_DIR/refs/` (which includes but is not
+ limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`)
be mirrored to the remote repository. Newly created local
refs will be pushed to the remote end, locally updated refs
will be force updated on the remote end, and deleted refs
--thin::
--no-thin::
- These options are passed to `git-send-pack`. Thin
+ These options are passed to 'git-send-pack'. Thin
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
Find a ref that matches `experimental` in the `origin` repository
(e.g. `refs/heads/experimental`), and delete it.
-git push origin master:satellite/master::
- Find a ref that matches `master` in the source repository
- (most likely, it would find `refs/heads/master`), and update
- the ref that matches `satellite/master` (most likely, it would
- be `refs/remotes/satellite/master`) in `origin` repository with it.
+git push origin master:satellite/master dev:satellite/dev::
+ Use the source ref that matches `master` (e.g. `refs/heads/master`)
+ to update the ref that matches `satellite/master` (most probably
+ `refs/remotes/satellite/master`) in the `origin` repository, then
+ do the same for `dev` and `satellite/dev`.
git push origin master:refs/heads/experimental::
Create the branch `experimental` in the `origin` repository
SYNOPSIS
--------
-'git-rerere' [clear|diff|status|gc]
+'git rerere' ['clear'|'diff'|'status'|'gc']
DESCRIPTION
-----------
COMMANDS
--------
-Normally, git-rerere is run without arguments or user-intervention.
+Normally, 'git-rerere' is run without arguments or user-intervention.
However, it has several commands that allow it to interact with
its working state.
'clear'::
This resets the metadata used by rerere if a merge resolution is to be
-is aborted. Calling linkgit:git-am[1] --skip or linkgit:git-rebase[1]
-[--skip|--abort] will automatically invoke this command.
+aborted. Calling 'git-am [--skip|--abort]' or 'git-rebase [--skip|--abort]'
+will automatically invoke this command.
'diff'::
This displays diffs for the current state of the resolution. It is
useful for tracking what has changed while the user is resolving
conflicts. Additional arguments are passed directly to the system
-diff(1) command installed in PATH.
+'diff' command installed in PATH.
'status'::
-Like diff, but this only prints the filenames that will be tracked
+Like 'diff', but this only prints the filenames that will be tracked
for resolutions.
'gc'::
The commits marked with `*` touch the same area in the same
file; you need to resolve the conflicts when creating the commit
- marked with `+`. Then you can test the result to make sure your
+ marked with `{plus}`. Then you can test the result to make sure your
work-in-progress still works with what is in the latest master.
After this test merge, there are two ways to continue your work
on the topic. The easiest is to build on top of the test merge
- commit `+`, and when your work in the topic branch is finally
+ commit `{plus}`, and when your work in the topic branch is finally
ready, pull the topic branch into master, and/or ask the
upstream to pull from you. By that time, however, the master or
- the upstream might have been advanced since the test merge `+`,
+ the upstream might have been advanced since the test merge `{plus}`,
in which case the final commit graph would look like this:
------------
would require you to resolve the conflict, introduced by the
commits marked with `*`. However, often this conflict is the
same conflict you resolved when you created the test merge you
-blew away. `git-rerere` command helps you to resolve this final
+blew away. 'git-rerere' command helps you to resolve this final
conflicted merge using the information from your earlier hand
resolve.
-Running `git-rerere` command immediately after a conflicted
+Running the 'git-rerere' command immediately after a conflicted
automerge records the conflicted working tree files, with the
usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
them. Later, after you are done resolving the conflicts,
-running `git-rerere` again records the resolved state of these
+running 'git-rerere' again records the resolved state of these
files. Suppose you did this when you created the test merge of
master into the topic branch.
-Next time, running `git-rerere` after seeing a conflicted
+Next time, running 'git-rerere' after seeing a conflicted
automerge, if the conflict is the same as the earlier one
recorded, it is noticed and a three-way merge between the
earlier conflicted automerge, the earlier manual resolution, and
the current conflicted automerge is performed by the command.
If this three-way merge resolves cleanly, the result is written
out to your working tree file, so you would not have to manually
-resolve it. Note that `git-rerere` leaves the index file alone,
+resolve it. Note that 'git-rerere' leaves the index file alone,
so you still need to do the final sanity checks with `git diff`
-(or `git diff -c`) and `git add` when you are satisfied.
+(or `git diff -c`) and 'git-add' when you are satisfied.
-As a convenience measure, `git-merge` automatically invokes
-`git-rerere` when it exits with a failed automerge, which
+As a convenience measure, 'git-merge' automatically invokes
+'git-rerere' when it exits with a failed automerge, which
records it if it is a new conflict, or reuses the earlier hand
-resolve when it is not. `git-commit` also invokes `git-rerere`
+resolve when it is not. 'git-commit' also invokes 'git-rerere'
when recording a merge result. What this means is that you do
not have to do anything special yourself (Note: you still have
to set the config variable rerere.enabled to enable this command).
actual merge later with updated master and topic branch, as long
as the earlier resolution is still applicable.
-The information `git-rerere` records is also used when running
-`git-rebase`. After blowing away the test merge and continuing
+The information 'git-rerere' records is also used when running
+'git-rebase'. After blowing away the test merge and continuing
development on the topic branch:
------------
up-to-date even before your topic is ready to be sent upstream.
This would result in falling back to three-way merge, and it
would conflict the same way the test merge you resolved earlier.
-`git-rerere` is run by `git rebase` to help you resolve this
+'git-rerere' is run by 'git-rebase' to help you resolve this
conflict.
<refspec>::
The canonical format of a <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `+`, followed
+ `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
[NOTE]
You never do your own development on branches that appear
on the right hand side of a <refspec> colon on `Pull:` lines;
-they are to be updated by `git-fetch`. If you intend to do
+they are to be updated by 'git-fetch'. If you intend to do
development derived from a remote branch `B`, have a `Pull:`
line to track it (i.e. `Pull: B:remote-B`), and have a separate
branch `my-B` to do your development on top of it. The latter
+
[NOTE]
There is a difference between listing multiple <refspec>
-directly on `git-pull` command line and having multiple
+directly on 'git-pull' command line and having multiple
`Pull:` <refspec> lines for a <repository> and running
-`git-pull` command without any explicit <refspec> parameters.
+'git-pull' command without any explicit <refspec> parameters.
<refspec> listed explicitly on the command line are always
merged into the current branch after fetching. In other words,
if you list more than one remote refs, you would be making
-an Octopus. While `git-pull` run without any explicit <refspec>
+an Octopus. While 'git-pull' run without any explicit <refspec>
parameter takes default <refspec>s from `Pull:` lines, it
merges only the first <refspec> found into the current branch,
after fetching all the remote refs. This is because making an