LinuxGuruz
  • Last 5 Forum Topics
    Replies
    Views
    Last post


The Web Only This Site
  • BOOKMARK

  • ADD TO FAVORITES

  • REFERENCES


  • MARC

    Mailing list ARChives
    - Search by -
     Subjects
     Authors
     Bodies





    FOLDOC

    Computing Dictionary




  • Text Link Ads






  • LINUX man pages
  • Linux Man Page Viewer


    The following form allows you to view linux man pages.

    Command:

    git-merge

    
    
    

    SYNOPSIS

           git merge [-n] [--stat] [--no-commit] [--squash]
                   [-s <strategy>] [-X <strategy-option>]
                   [--[no-]rerere-autoupdate] [-m <msg>] <commit>...
           git merge <msg> HEAD <commit>...
    
    
    

    DESCRIPTION

           Incorporates changes from the named commits (since the time their
           histories diverged from the current branch) into the current branch.
           This command is used by git pull to incorporate changes from another
           repository and can be used by hand to merge changes from one branch
           into another.
    
           Assume the following history exists and the current branch is "master":
    
                         A---B---C topic
                        /
                   D---E---F---G master
    
           Then "git merge topic" will replay the changes made on the topic branch
           since it diverged from master (i.e., E) until its current commit (C) on
           top of master, and record the result in a new commit along with the
           names of the two parent commits and a log message from the user
           describing the changes.
    
                         A---B---C topic
                        /         \
                   D---E---F---G---H master
    
           The second syntax (<msg> HEAD <commit>...) 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> <commit>....
    
           Warning: Running git merge with uncommitted changes is discouraged:
           while possible, it leaves you in a state that is hard to back out of in
           the case of a conflict.
    
    
    

    OPTIONS

           --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.
    
           --ff, --no-ff
               Do not generate a merge commit if the merge resolved as a
               fast-forward, only update the branch pointer. This is the default
               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.
    
           --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.
    
           -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.
    
           -v, --verbose
               Be verbose.
    
           -m <msg>
               Set the commit message to be used for the merge commit (in case one
               is created). The git fmt-merge-msg command can be used to give a
               good default for automated git merge invocations.
    
           --rerere-autoupdate, --no-rerere-autoupdate
               Allow the rerere mechanism to update the index with the result of
               auto-conflict resolution if possible.
    
           <commit>...
           index entries are in the state that would result from the merge
           already.)
    
           If all named commits are already ancestors of HEAD, git merge will exit
           early with the message "Already up-to-date."
    
    
    

    FAST-FORWARD MERGE

           Often the current branch head is an ancestor of the named commit. This
           is the most common case especially when invoked from git pull: you are
           tracking an upstream repository, you have committed no local changes,
           and now you want to update to a newer upstream revision. In this case,
           a new commit is not needed to store the combined history; instead, the
           HEAD (along with the index) is updated to point at the named commit,
           without creating an extra merge commit.
    
           This behavior can be suppressed with the --no-ff option.
    
    
    

    TRUE MERGE

           Except in a fast-forward merge (see above), the branches to be merged
           must be tied together by a merge commit that has both of them as its
           parents.
    
           A merged version reconciling the changes from all branches to be merged
           is committed, and your HEAD, index, and working tree are updated to it.
           It is possible to have modifications in the working tree as long as
           they do not overlap; the update will preserve them.
    
           When it is not obvious how to reconcile the changes, the following
           happens:
    
            1. The HEAD pointer stays the same.
    
            2. The MERGE_HEAD ref is set to point to the other branch head.
    
            3. Paths that merged cleanly are updated both in the index file and in
               your working tree.
    
            4. For conflicting paths, the index file records up to three versions:
               stage 1 stores the version from the common ancestor, stage 2 from
               HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with
               git ls-files -u). The working tree files contain the result of the
               "merge" program; i.e. 3-way merge results with familiar conflict
               markers <<< === >>>.
    
            5. No other changes are made. 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.
    
           If you tried a merge which resulted in complex conflicts and want to
           start over, you can recover with git reset --merge.
    
    
    

    HOW CONFLICTS ARE PRESENTED

               <<<<<<< yours:sample.txt
               Conflict resolution is hard;
               let?s go shopping.
               =======
               Git makes conflict resolution easy.
               >>>>>>> theirs:sample.txt
               And here is another line that is cleanly resolved or unmodified.
    
           The area where a pair of conflicting changes happened is marked with
           markers <<<<<<<, =======, and >>>>>>>. The part before the ======= is
           typically your side, and the part afterwards is typically their side.
    
           The default format does not show what the original said in the
           conflicting area. You cannot tell how many lines are deleted and
           replaced with Barbie's remark on your side. The only thing you can tell
           is that your side wants to say it is hard and you'd prefer to go
           shopping, while the other side wants to claim it is easy.
    
           An alternative style can be used by setting the "merge.conflictstyle"
           configuration variable to "diff3". In "diff3" style, the above conflict
           may look like this:
    
               Here are lines that are either unchanged from the common
               ancestor, or cleanly resolved because only one side changed.
               <<<<<<< yours:sample.txt
               Conflict resolution is hard;
               let?s go shopping.
               |||||||
               Conflict resolution is hard.
               =======
               Git makes conflict resolution easy.
               >>>>>>> theirs:sample.txt
               And here is another line that is cleanly resolved or unmodified.
    
           In addition to the <<<<<<<, =======, and >>>>>>> markers, it uses
           another ||||||| marker that is followed by the original text. You can
           tell that the original just stated a fact, and your side simply gave in
           to that statement and gave up, while the other side tried to have a
           more positive attitude. You can sometimes come up with a better
           resolution by viewing the original.
    
    
    

    HOW TO RESOLVE CONFLICTS

           After seeing a conflict, you can do two things:
    
           ?   Decide not to merge. The only clean-ups 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 --hard can be used for
               this.
    
           ?   Resolve the conflicts. Git will mark the conflicts in the working
    
           ?   Look at the originals.  git show :1:filename shows the common
               ancestor, git show :2:filename shows the HEAD version, and git show
               :3:filename shows the MERGE_HEAD version.
    
    
    

    EXAMPLES

           ?   Merge branches fixes and enhancements on top of the current branch,
               making an octopus merge:
    
                   $ git merge fixes enhancements
    
           ?   Merge branch obsolete into the current branch, using ours merge
               strategy:
    
                   $ git merge -s ours obsolete
    
           ?   Merge branch maint into the current branch, but do not make a new
               commit automatically:
    
                   $ git merge --no-commit maint
    
               This can be used when you want to include further changes to the
               merge, or want to write your own merge commit message.
    
               You should refrain from abusing this option to sneak substantial
               changes into a merge commit. Small fixups like bumping
               release/version name would be acceptable.
    
    
    

    MERGE STRATEGIES

           The merge mechanism (git-merge and git-pull commands) allows the
           backend merge strategies to be chosen with -s option. Some strategies
           can also take their own options, which can be passed by giving
           -X<option> arguments to git-merge and/or git-pull.
    
           resolve
               This can only resolve two heads (i.e. the current branch and
               another branch you pulled from) using a 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 a 3-way merge algorithm. When
               there is more than one common ancestor 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.
               theirs
                   This is opposite of ours.
    
               subtree[=path]
                   This option is a more advanced form of subtree strategy, where
                   the strategy makes a guess on how two trees must be shifted to
                   match with each other when merging. Instead, the specified path
                   is prefixed (or stripped from the beginning) to make the shape
                   of two trees to match.
    
           octopus
               This resolves cases with more than two heads, but refuses to do a
               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
               branch.
    
           ours
               This resolves any number of heads, but the resulting tree of the
               merge is always that of the current branch head, effectively
               ignoring all changes from all other branches. It is meant to be
               used to supersede old development history of side branches. Note
               that this is different from the -Xours option to the recursive
               merge strategy.
    
           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.
    
    
    

    CONFIGURATION

           merge.conflictstyle
               Specify the style in which conflicted hunks are written out to
               working tree files upon merge. The default is "merge", which shows
               a <<<<<<< conflict marker, changes made by one side, a =======
               marker, changes made by the other side, and then a >>>>>>> marker.
               An alternate style, "diff3", adds a ||||||| marker and the original
               text before the ======= marker.
    
           merge.log
               Whether to include summaries of merged commits in newly created
               merge commit messages. False by default.
    
           merge.renameLimit
               The number of files to consider when performing rename detection
               during a merge; if not specified, defaults to the value of
               diff.renameLimit.
    
           merge.stat
               Whether to print the diffstat between ORIG_HEAD and the merge
               result at the end of the merge. True by default.
               information. The default is level 2. Can be overridden by the
               GIT_MERGE_VERBOSITY environment variable.
    
           merge.<driver>.name
               Defines a human-readable name for a custom low-level merge driver.
               See gitattributes(5) for details.
    
           merge.<driver>.driver
               Defines the command that implements a custom low-level merge
               driver. See gitattributes(5) for details.
    
           merge.<driver>.recursive
               Names a low-level merge driver to be used when performing an
               internal merge between common ancestors. See gitattributes(5) for
               details.
    
           branch.<name>.mergeoptions
               Sets default options for merging into branch <name>. The syntax and
               supported options are the same as those of git merge, but option
               values containing whitespace characters are currently not
               supported.
    
    
    

    SEE ALSO

           git-fmt-merge-msg(1), git-pull(1), gitattributes(5), git-reset(1), git-
           diff(1), git-ls-files(1), git-add(1), git-rm(1), git-mergetool(1)
    
    
    

    AUTHOR

           Written by Junio C Hamano <gitster@pobox.com[1]>
    
    
    

    DOCUMENTATION

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

    GIT

           Part of the git(1) suite
    
    
    

    NOTES

            1. gitster@pobox.com
               mailto:gitster@pobox.com
    
            2. git@vger.kernel.org
               mailto:git@vger.kernel.org
    
    
    

    Git 1.7.1 03/04/2013 GIT-MERGE(1)

    
    
  • MORE RESOURCE


  • Linux

    The Distributions





    Linux

    The Software





    Linux

    The News



  • MARKETING






  • Toll Free

webmaster@linuxguruz.com
Copyright © 1999 - 2016 by LinuxGuruz