2a7131874be370579f2f1ef4a72074b5d8b86141
   1<repository>::
   2        The "remote" repository that is the source of a fetch
   3        or pull operation, or the destination of a push operation.
   4        One of the following notations can be used
   5        to name the remote repository:
   6+
   7===============================================================
   8- Rsync URL:            rsync://remote.machine/path/to/repo.git/
   9- HTTP(s) URL:          http://remote.machine/path/to/repo.git/
  10- git URL:              git://remote.machine/path/to/repo.git/
  11                        or remote.machine:/path/to/repo.git/
  12- Local directory:      /path/to/repo.git/
  13===============================================================
  14+
  15In addition to the above, as a short-hand, the name of a
  16file in `$GIT_DIR/remotes` directory can be given; the
  17named file should be in the following format:
  18+
  19        URL: one of the above URL format
  20        Push: <refspec>...
  21        Pull: <refspec>...
  22+
  23When such a short-hand is specified in place of
  24<repository> without <refspec> parameters on the command
  25line, <refspec>... specified on `Push:` lines or `Pull:`
  26lines are used for `git-push` and `git-fetch`/`git-pull`,
  27respectively.  Multiple `Push:` and and `Pull:` lines may
  28be specified for additional branch mappings.
  29+
  30The name of a file in `$GIT_DIR/branches` directory can be
  31specified as an older notation short-hand; the named
  32file should contain a single line, a URL in one of the
  33above formats, optionally followed by a hash `#` and the
  34name of remote head (URL fragment notation).
  35`$GIT_DIR/branches/<remote>` file that stores a <url>
  36without the fragment is equivalent to have this in the
  37corresponding file in the `$GIT_DIR/remotes/` directory.
  38+
  39        URL: <url>
  40        Pull: refs/heads/master:<remote>
  41+
  42while having `<url>#<head>` is equivalent to
  43+
  44        URL: <url>
  45        Pull: refs/heads/<head>:<remote>
  46
  47<refspec>::
  48        The canonical format of a <refspec> parameter is
  49        `+?<src>:<dst>`; that is, an optional plus `+`, followed
  50        by the source ref, followed by a colon `:`, followed by
  51        the destination ref.
  52+
  53When used in `git-push`, the <src> side can be an
  54arbitrary "SHA1 expression" that can be used as an
  55argument to `git-cat-file -t`.  E.g. `master~4` (push
  56four parents before the current master head).
  57+
  58For `git-push`, the local ref that matches <src> is used
  59to fast forward the remote ref that matches <dst>.  If
  60the optional plus `+` is used, the remote ref is updated
  61even if it does not result in a fast forward update.
  62+
  63For `git-fetch` and `git-pull`, the remote ref that matches <src>
  64is fetched, and if <dst> is not empty string, the local
  65ref that matches it is fast forwarded using <src>.
  66Again, if the optional plus `+` is used, the local ref
  67is updated even if it does not result in a fast forward
  68update.
  69+
  70[NOTE]
  71If the remote branch from which you want to pull is
  72modified in non-linear ways such as being rewound and
  73rebased frequently, then a pull will attempt a merge with
  74an older version of itself, likely conflict, and fail.
  75It is under these conditions that you would want to use
  76the `+` sign to indicate non-fast-forward updates will
  77be needed.  There is currently no easy way to determine
  78or declare that a branch will be made available in a
  79repository with this behavior; the pulling user simply
  80must know this is the expected usage pattern for a branch.
  81+
  82[NOTE]
  83You never do your own development on branches that appear
  84on the right hand side of a <refspec> colon on `Pull:` lines;
  85they are to be updated by `git-fetch`.  The corollary is that
  86a local branch should be introduced and named on a <refspec>
  87right-hand-side if you intend to do development derived from
  88that branch.
  89This leads to the common `Pull: master:origin` mapping of a
  90remote `master` branch to a local `origin` branch, which
  91is then merged to a local development branch, again typically
  92named `master`.
  93+
  94Some short-cut notations are also supported.
  95+
  96* For backward compatibility, `tag` is almost ignored;
  97  it just makes the following parameter <tag> to mean a
  98  refspec `refs/tags/<tag>:refs/tags/<tag>`.
  99* A parameter <ref> without a colon is equivalent to
 100  <ref>: when pulling/fetching, and <ref>`:`<ref> when
 101  pushing.  That is, do not store it locally if
 102  fetching, and update the same name if pushing.
 103