git-pull(1) - Fetch from and merge with another repository or a local branch
-q, --quiet
    This is passed to both underlying git-fetch to squelch reporting of during transfer, and underlying
    git-merge to squelch output during merging.
-v, --verbose
    Pass --verbose to git-fetch and git-merge.
Options related to merging
    --commit, --no-commit
        Perform the merge and commit the result. This option can be used to override --no-commit.

        With --no-commit perform the merge but pretend the merge failed and do not autocommit, to give the
        user a chance to inspect and further tweak the merge result before committing.
--edit, -e
    Invoke editor before committing successful merge to further edit the default merge message.
--ff
    When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge
    commit. This is the default behavior.
--no-ff
    Create a merge commit even when the merge resolves as a fast-forward.
--ff-only
    Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the
    merge can be resolved as a fast-forward.
--log[=<n>], --no-log
    In addition to branch names, populate the log message with one-line descriptions from at most <n>
    actual commits that are being merged. See also git-fmt-merge-msg(1).

    With --no-log do not list one-line descriptions from the actual commits being merged.
--stat, -n, --no-stat
    Show a diffstat at the end of the merge. The diffstat is also controlled by the configuration option
    merge.stat.

    With -n or --no-stat do not show a diffstat at the end of the merge.
--squash, --no-squash
    Produce the working tree and index state as if a real merge happened (except for the merge
    information), but do not actually make a commit or move the HEAD, nor record $GIT_DIR/MERGE_HEAD to
    cause the next git commit command to create a merge commit. This allows you to create a single commit
    on top of the current branch whose effect is the same as merging another branch (or more in case of
    an octopus).

    With --no-squash perform the merge and commit the result. This option can be used to override
    --squash.
-s <strategy>, --strategy=<strategy>
    Use the given merge strategy; can be supplied more than once to specify them in the order they should
    be tried. If there is no -s option, a built-in list of strategies is used instead (git
    merge-recursive when merging a single head, git merge-octopus otherwise).
-X <option>, --strategy-option=<option>
    Pass merge strategy specific option through to the merge strategy.
--summary, --no-summary
    Synonyms to --stat and --no-stat; these are deprecated and will be removed in the future.
-q, --quiet
    Operate quietly. Implies --no-progress.
-v, --verbose
    Be verbose.
--progress, --no-progress
    Turn progress on/off explicitly. If neither is specified, progress is shown if standard error is
    connected to a terminal. Note that not all merge strategies may support progress reporting.
--rebase
    Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking
    branch corresponding to the upstream branch and the upstream branch was rebased since last fetched,
    the rebase uses that information to avoid rebasing non-local changes.

    See pull.rebase, branch.<name>.rebase and branch.autosetuprebase in git-config(1) if you want to make
    git pull always use --rebase instead of merging.

        Note
        This is a potentially dangerous mode of operation. It rewrites history, which does not bode well
        when you published that history already. Do not use this option unless you have read git-
        rebase(1) carefully.
--no-rebase
    Override earlier --rebase.
Options related to fetching
    --all
        Fetch all remotes.
-a, --append
    Append ref names and object names of fetched refs to the existing contents of .git/FETCH_HEAD.
    Without this option old data in .git/FETCH_HEAD will be overwritten.
--depth=<depth>
    Deepen the history of a shallow repository created by git clone with --depth=<depth> option (see git-
    clone(1)) by the specified number of commits.
-f, --force
    When git fetch is used with <rbranch>:<lbranch> refspec, it refuses to update the local branch
    <lbranch> unless the remote branch <rbranch> it fetches is a descendant of <lbranch>. This option
    overrides that check.
-k, --keep
    Keep downloaded pack.
--no-tags
    By default, tags that point at objects that are downloaded from the remote repository are fetched and
    stored locally. This option disables this automatic tag following. The default behavior for a remote
    may be specified with the remote.<name>.tagopt setting. See git-config(1).
-u, --update-head-ok
    By default git fetch refuses to update the head which corresponds to the current branch. This flag
    disables the check. This is purely for the internal use for git pull to communicate with git fetch,
    and unless you are implementing your own Porcelain you are not supposed to use it.
--upload-pack <upload-pack>
    When given, and the repository to fetch from is handled by git fetch-pack, --exec=<upload-pack> is
    passed to the command to specify non-default path for the command run on the other end.
--progress
    Progress status is reported on the standard error stream by default when it is attached to a
    terminal, unless -q is specified. This flag forces progress status even if the standard error stream
    is not directed to a terminal.
<repository>
    The "remote" repository that is the source of a fetch or pull operation. This parameter can be either
    a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).

<refspec>
    The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed
    by a colon :, followed by the destination ref <dst>.