100
101
This behavior can be suppressed with the `--no-ff` option.
102
103
-HOW MERGE WORKS
104
----------------
105
-
106
-A merge is always between the current `HEAD` and one or more
107
-commits (usually a branch head or tag).
103
+TRUE MERGE
104
+----------
105
106
Except in a fast-forward merge (see above), the branches to be
107
merged must be tied together by a merge commit that has both of them
108
as its parents.
112
-The rest of this section describes this "True merge" case.
113
-
114
-The chosen merge strategy merges the two commits into a single
115
-new source tree.
116
-When things merge cleanly, this is what happens:
117
-
118
-1. The results are updated both in the index file and in your
119
- working tree;
120
-2. Index file is written out as a tree;
121
-3. The tree gets committed; and
122
-4. The `HEAD` pointer gets advanced.
109
124
-Because of 2., we require that the original state of the index
125
-file matches exactly the current `HEAD` commit; otherwise we
126
-will write out your local changes already registered in your
127
-index file along with the merge result, which is not good.
128
-Because 1. involves only those paths differing between your
129
-branch and the branch you are merging
130
-(which is typically a fraction of the whole tree), you can
131
-have local modifications in your working tree as long as they do
132
-not overlap with what the merge updates.
110
+A merged version reconciling the changes from all branches to be
111
+merged is committed, and your `HEAD`, index, and working tree are
112
+updated to it. It is possible to have modifications in the working
113
+tree as long as they do not overlap; the update will preserve them.
114
134
-When there are conflicts, the following happens:
115
+When it is not obvious how to reconcile the changes, the following
116
+happens:
117
136
-1. `HEAD` stays the same.
137
-
138
-2. Cleanly merged paths are updated both in the index file and
118
+1. The `HEAD` pointer stays the same.
119
+2. The `MERGE_HEAD` ref is set to point to the other branch head.
120
+3. Paths that merged cleanly are updated both in the index file and
121
in your working tree.
140
-
141
-3. For conflicting paths, the index file records up to three
142
- versions; stage1 stores the version from the common ancestor,
143
- stage2 from `HEAD`, and stage3 from the other branch (you
122
+4. For conflicting paths, the index file records up to three
123
+ versions: stage 1 stores the version from the common ancestor,
124
+ stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you
125
can inspect the stages with `git ls-files -u`). The working
126
tree files contain the result of the "merge" program; i.e. 3-way
146
- merge results with familiar conflict markers `<<< === >>>`.
147
-
148
-4. No other changes are done. In particular, the local
127
+ merge results with familiar conflict markers `<<<` `===` `>>>`.
128
+5. No other changes are made. In particular, the local
129
modifications you had before you started merge will stay the
130
same and the index entries for them stay as they were,
131
i.e. matching `HEAD`.