git-merge man page on YellowDog

Man page or keyword search:  
man Server   18644 pages
apropos Keyword Search (all sections)
Output format
YellowDog logo
[printable version]

GIT-MERGE(1)			  Git Manual			  GIT-MERGE(1)

NAME
       git-merge - Join two or more development histories together

SYNOPSIS
       git-merge [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]...
	       [-m <msg>] <remote> <remote>...
       git-merge <msg> HEAD <remote>...

DESCRIPTION
       This is the top-level interface to the merge machinery which drives
       multiple merge strategy scripts.

       The second syntax (<msg> HEAD <remote>) is supported for historical
       reasons. Do not use it from the command line or in new scripts. It is
       the same as git merge -m <msg> <remote>.

OPTIONS
       --summary
	      Show a diffstat at the end of the merge. The diffstat is also
	      controlled by the configuration option merge.diffstat.

       -n, --no-summary
	      Do not show diffstat at the end of the merge.

       --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.

       --commit
	      Perform the merge and commit the result. This option can be used
	      to override --no-commit.

       --squash
	      Produce the working tree and index state as if a real merge
	      happened, 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).

       --no-squash
	      Perform the merge and commit the result. This option can be used
	      to override --squash.

       --no-ff
	      Generate a merge commit even if the merge resolved as a
	      fast-forward.

       --ff   Do not generate a merge commit if the merge resolved as a
	      fast-forward, only update the branch pointer. This is the
	      default behavior of git-merge.

       -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).

       -m <msg>
	      The commit message to be used for the merge commit (in case it
	      is created). The git-fmt-merge-msg script can be used to give a
	      good default for automated git-merge invocations.

       <remote>
	      Other branch head merged into our branch. You need at least one
	      <remote>. Specifying more than one <remote> obviously means you
	      are trying an Octopus.

MERGE STRATEGIES
       resolve
	      This can only resolve two heads (i.e. the current branch and
	      another branch you pulled from) using 3-way merge algorithm. It
	      tries to carefully detect criss-cross merge ambiguities and is
	      considered generally safe and fast.

       recursive
	      This can only resolve two heads using 3-way merge algorithm.
	      When there are more than one common ancestors that can be used
	      for 3-way merge, it creates a merged tree of the common
	      ancestors and uses that as the reference tree for the 3-way
	      merge. This has been reported to result in fewer merge conflicts
	      without causing mis-merges by tests done on actual merge commits
	      taken from Linux 2.6 kernel development history. Additionally
	      this can detect and handle merges involving renames. This is the
	      default merge strategy when pulling or merging one branch.

       octopus
	      This resolves more than two-head case, but refuses to do complex
	      merge that needs manual resolution. It is primarily meant to be
	      used for bundling topic branch heads together. This is the
	      default merge strategy when pulling or merging more than one
	      branches.

       ours   This resolves any number of heads, but the result of the merge
	      is always the current branch head. It is meant to be used to
	      supersede old development history of side branches.

       subtree
	      This is a modified recursive strategy. When merging trees A and
	      B, if B corresponds to a subtree of A, B is first adjusted to
	      match the tree structure of A, instead of reading the trees at
	      the same level. This adjustment is also done to the common
	      ancestor tree.

	      If you tried a merge which resulted in a complex conflicts and
	      would want to start over, you can recover with git-reset(1).

CONFIGURATION
       merge.summary
	      Whether to include summaries of merged commits in newly created
	      merge commit. False by default.

       merge.verbosity
	      Controls the amount of output shown by the recursive merge
	      strategy. Level 0 outputs nothing except a final error message
	      if conflicts were detected. Level 1 outputs only conflicts, 2
	      outputs conflicts and file changes. Level 5 and above outputs
	      debugging information. The default is level 2. Can be overridden
	      by GIT_MERGE_VERBOSITY environment variable.

       branch.<name>.mergeoptions
	      Sets default options for merging into branch <name>. The syntax
	      and supported options are equal to that of git-merge, but option
	      values containing whitespace characters are currently not
	      supported.

HOW MERGE WORKS
       A merge is always between the current HEAD and one or more commits
       (usually, branch head or tag), and the index file must exactly match
       the tree of HEAD commit (i.e. the contents of the last commit) when it
       happens. In other words, git-diff --cached HEAD must report no changes.

       Note
       This is a bit of a lie. In certain special cases, your index is allowed
       to be different from the tree of the HEAD commit. The most notable case
       is when your HEAD commit is already ahead of what is being merged, in
       which case your index can have arbitrary differences from your HEAD
       commit. Also, your index entries may have differences from your HEAD
       commit that match the result of a trivial merge (e.g. you received the
       same patch from an external source to produce the same result as what
       you are merging). For example, if a path did not exist in the common
       ancestor and your head commit but exists in the tree you are merging
       into your repository, and if you already happen to have that path
       exactly in your index, the merge does not have to fail.

       Otherwise, merge will refuse to do any harm to your repository (that
       is, it may fetch the objects from remote, and it may even update the
       local branch used to keep track of the remote branch with git pull
       remote rbranch:lbranch, but your working tree, .git/HEAD pointer and
       index file are left intact).

       You may have local modifications in the working tree files. In other
       words, git-diff is allowed to report changes. However, the merge uses
       your working tree as the working area, and in order to prevent the
       merge operation from losing such changes, it makes sure that they do
       not interfere with the merge. Those complex tables in read-tree
       documentation define what it means for a path to "interfere with the
       merge". And if your local modifications interfere with the merge,
       again, it stops before touching anything.

       So in the above two "failed merge" case, you do not have to worry about
       loss of data --- you simply were not ready to do a merge, so no merge
       happened at all. You may want to finish whatever you were in the middle
       of doing, and retry the same pull after you are done and ready.

       When things cleanly merge, these things happen:

       1. The results are updated both in the index file and in your working
	  tree;

       2. Index file is written out as a tree;

       3. The tree gets committed; and

       4. The HEAD pointer gets advanced.

	  Because of 2., we require that the original state of the index file
	  to match exactly the current HEAD commit; otherwise we will write
	  out your local changes already registered in your index file along
	  with the merge result, which is not good. Because 1. involves only
	  the paths different between your branch and the remote branch you
	  are pulling from during the merge (which is typically a fraction of
	  the whole tree), you can have local modifications in your working
	  tree as long as they do not overlap with what the merge updates.

	  When there are conflicts, these things happen:

       1. HEAD stays the same.

       2. Cleanly merged paths are updated both in the index file and in your
	  working tree.

       3. For conflicting paths, the index file records up to three versions;
	  stage1 stores the version from the common ancestor, stage2 from
	  HEAD, and stage3 from the remote branch (you can inspect the stages
	  with git-ls-files -u). The working tree files have the result of
	  "merge" program; i.e. 3-way merge result with familiar conflict
	  markers <<< === >>>.

       4. No other changes are done. In particular, the local modifications
	  you had before you started merge will stay the same and the index
	  entries for them stay as they were, i.e. matching HEAD.

	  After seeing a conflict, you can do two things:

       ·  Decide not to merge. The only clean-up you need are to reset the
	  index file to the HEAD commit to reverse 2. and to clean up working
	  tree changes made by 2. and 3.; git-reset can be used for this.

       ·  Resolve the conflicts. git-diff would report only the conflicting
	  paths because of the above 2. and 3.. Edit the working tree files
	  into a desirable shape, git-add or git-rm them, to make the index
	  file contain what the merge result should be, and run git-commit to
	  commit the result.

SEE ALSO
       git-fmt-merge-msg(1), git-pull(1), gitattributes(5)

AUTHOR
       Written by Junio C Hamano <junkio@cox.net>

DOCUMENTATION
       Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.

GIT
       Part of the git(7) suite

Git 1.5.5.2			  10/21/2008			  GIT-MERGE(1)
[top]

List of man pages available for YellowDog

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net