diff options
Diffstat (limited to 'third_party/git/Documentation/merge-strategies.txt')
| -rw-r--r-- | third_party/git/Documentation/merge-strategies.txt | 136 |
1 files changed, 0 insertions, 136 deletions
diff --git a/third_party/git/Documentation/merge-strategies.txt b/third_party/git/Documentation/merge-strategies.txt deleted file mode 100644 index 2912de706bf3..000000000000 --- a/third_party/git/Documentation/merge-strategies.txt +++ /dev/null @@ -1,136 +0,0 @@ -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 mismerges by tests done on actual merge commits - taken from Linux 2.6 kernel development history. - Additionally this can detect and handle merges involving - renames, but currently cannot make use of detected - copies. This is the default merge strategy when pulling - or merging one branch. -+ -The 'recursive' strategy can take the following options: - -ours;; - This option forces conflicting hunks to be auto-resolved cleanly by - favoring 'our' version. Changes from the other tree that do not - conflict with our side are reflected in the merge result. - For a binary file, the entire contents are taken from our side. -+ -This should not be confused with the 'ours' merge strategy, which does not -even look at what the other tree contains at all. It discards everything -the other tree did, declaring 'our' history contains all that happened in it. - -theirs;; - This is the opposite of 'ours'; note that, unlike 'ours', there is - no 'theirs' merge strategy to confuse this merge option with. - -patience;; - With this option, 'merge-recursive' spends a little extra time - to avoid mismerges that sometimes occur due to unimportant - matching lines (e.g., braces from distinct functions). Use - this when the branches to be merged have diverged wildly. - See also linkgit:git-diff[1] `--patience`. - -diff-algorithm=[patience|minimal|histogram|myers];; - Tells 'merge-recursive' to use a different diff algorithm, which - can help avoid mismerges that occur due to unimportant matching - lines (such as braces from distinct functions). See also - linkgit:git-diff[1] `--diff-algorithm`. - -ignore-space-change;; -ignore-all-space;; -ignore-space-at-eol;; -ignore-cr-at-eol;; - Treats lines with the indicated type of whitespace change as - unchanged for the sake of a three-way merge. Whitespace - changes mixed with other changes to a line are not ignored. - See also linkgit:git-diff[1] `-b`, `-w`, - `--ignore-space-at-eol`, and `--ignore-cr-at-eol`. -+ -* If 'their' version only introduces whitespace changes to a line, - 'our' version is used; -* If 'our' version introduces whitespace changes but 'their' - version includes a substantial change, 'their' version is used; -* Otherwise, the merge proceeds in the usual way. - -renormalize;; - This runs a virtual check-out and check-in of all three stages - of a file when resolving a three-way merge. This option is - meant to be used when merging branches with different clean - filters or end-of-line normalization rules. See "Merging - branches with differing checkin/checkout attributes" in - linkgit:gitattributes[5] for details. - -no-renormalize;; - Disables the `renormalize` option. This overrides the - `merge.renormalize` configuration variable. - -no-renames;; - Turn off rename detection. This overrides the `merge.renames` - configuration variable. - See also linkgit:git-diff[1] `--no-renames`. - -find-renames[=<n>];; - Turn on rename detection, optionally setting the similarity - threshold. This is the default. This overrides the - 'merge.renames' configuration variable. - See also linkgit:git-diff[1] `--find-renames`. - -rename-threshold=<n>;; - Deprecated synonym for `find-renames=<n>`. - -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. - -With the strategies that use 3-way merge (including the default, 'recursive'), -if a change is made on both branches, but later reverted on one of the -branches, that change will be present in the merged result; some people find -this behavior confusing. It occurs because only the heads and the merge base -are considered when performing a merge, not the individual commits. The merge -algorithm therefore considers the reverted change as no change at all, and -substitutes the changed version instead. |