Documentation / merge-options.txton commit checkout & worktree: introduce checkout.defaultRemote (8d7b558)
   1--commit::
   2--no-commit::
   3        Perform the merge and commit the result. This option can
   4        be used to override --no-commit.
   5+
   6With --no-commit perform the merge but pretend the merge
   7failed and do not autocommit, to give the user a chance to
   8inspect and further tweak the merge result before committing.
   9
  10--edit::
  11-e::
  12--no-edit::
  13        Invoke an editor before committing successful mechanical merge to
  14        further edit the auto-generated merge message, so that the user
  15        can explain and justify the merge. The `--no-edit` option can be
  16        used to accept the auto-generated message (this is generally
  17        discouraged).
  18ifndef::git-pull[]
  19The `--edit` (or `-e`) option is still useful if you are
  20giving a draft message with the `-m` option from the command line
  21and want to edit it in the editor.
  22endif::git-pull[]
  23+
  24Older scripts may depend on the historical behaviour of not allowing the
  25user to edit the merge log message. They will see an editor opened when
  26they run `git merge`. To make it easier to adjust such scripts to the
  27updated behaviour, the environment variable `GIT_MERGE_AUTOEDIT` can be
  28set to `no` at the beginning of them.
  29
  30--ff::
  31        When the merge resolves as a fast-forward, only update the branch
  32        pointer, without creating a merge commit.  This is the default
  33        behavior.
  34
  35--no-ff::
  36        Create a merge commit even when the merge resolves as a
  37        fast-forward.  This is the default behaviour when merging an
  38        annotated (and possibly signed) tag that is not stored in
  39        its natural place in 'refs/tags/' hierarchy.
  40
  41--ff-only::
  42        Refuse to merge and exit with a non-zero status unless the
  43        current `HEAD` is already up to date or the merge can be
  44        resolved as a fast-forward.
  45
  46-S[<keyid>]::
  47--gpg-sign[=<keyid>]::
  48        GPG-sign the resulting merge commit. The `keyid` argument is
  49        optional and defaults to the committer identity; if specified,
  50        it must be stuck to the option without a space.
  51
  52--log[=<n>]::
  53--no-log::
  54        In addition to branch names, populate the log message with
  55        one-line descriptions from at most <n> actual commits that are being
  56        merged. See also linkgit:git-fmt-merge-msg[1].
  57+
  58With --no-log do not list one-line descriptions from the
  59actual commits being merged.
  60
  61--signoff::
  62--no-signoff::
  63        Add Signed-off-by line by the committer at the end of the commit
  64        log message.  The meaning of a signoff depends on the project,
  65        but it typically certifies that committer has
  66        the rights to submit this work under the same license and
  67        agrees to a Developer Certificate of Origin
  68        (see http://developercertificate.org/ for more information).
  69+
  70With --no-signoff do not add a Signed-off-by line.
  71
  72--stat::
  73-n::
  74--no-stat::
  75        Show a diffstat at the end of the merge. The diffstat is also
  76        controlled by the configuration option merge.stat.
  77+
  78With -n or --no-stat do not show a diffstat at the end of the
  79merge.
  80
  81--squash::
  82--no-squash::
  83        Produce the working tree and index state as if a real merge
  84        happened (except for the merge information), but do not actually
  85        make a commit, move the `HEAD`, or record `$GIT_DIR/MERGE_HEAD`
  86        (to cause the next `git commit` command to create a merge
  87        commit).  This allows you to create a single commit on top of
  88        the current branch whose effect is the same as merging another
  89        branch (or more in case of an octopus).
  90+
  91With --no-squash perform the merge and commit the result. This
  92option can be used to override --squash.
  93
  94-s <strategy>::
  95--strategy=<strategy>::
  96        Use the given merge strategy; can be supplied more than
  97        once to specify them in the order they should be tried.
  98        If there is no `-s` option, a built-in list of strategies
  99        is used instead ('git merge-recursive' when merging a single
 100        head, 'git merge-octopus' otherwise).
 101
 102-X <option>::
 103--strategy-option=<option>::
 104        Pass merge strategy specific option through to the merge
 105        strategy.
 106
 107--verify-signatures::
 108--no-verify-signatures::
 109        Verify that the tip commit of the side branch being merged is
 110        signed with a valid key, i.e. a key that has a valid uid: in the
 111        default trust model, this means the signing key has been signed by
 112        a trusted key.  If the tip commit of the side branch is not signed
 113        with a valid key, the merge is aborted.
 114
 115--summary::
 116--no-summary::
 117        Synonyms to --stat and --no-stat; these are deprecated and will be
 118        removed in the future.
 119
 120ifndef::git-pull[]
 121-q::
 122--quiet::
 123        Operate quietly. Implies --no-progress.
 124
 125-v::
 126--verbose::
 127        Be verbose.
 128
 129--progress::
 130--no-progress::
 131        Turn progress on/off explicitly. If neither is specified,
 132        progress is shown if standard error is connected to a terminal.
 133        Note that not all merge strategies may support progress
 134        reporting.
 135
 136endif::git-pull[]
 137
 138--allow-unrelated-histories::
 139        By default, `git merge` command refuses to merge histories
 140        that do not share a common ancestor.  This option can be
 141        used to override this safety when merging histories of two
 142        projects that started their lives independently. As that is
 143        a very rare occasion, no configuration variable to enable
 144        this by default exists and will not be added.