aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/merge-strategies.txt
AgeCommit message (Collapse)AuthorFilesLines
2021-08-05Update docs for change of default merge backendElijah Newren1-43/+50
Make it clear that `ort` is the default merge strategy now rather than `recursive`, including moving `ort` to the front of the list of merge strategies. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: add coverage of the `ort` merge strategyElijah Newren1-0/+14
Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: avoid giving special preference to patience algorithmElijah Newren1-5/+1
We already have diff-algorithm that explains why there are special diff algorithms, so we do not need to re-explain patience. patience exists as its own toplevel option for historical reasons, but there's no reason to give it special preference or document it again and suggest it's more important than other diff algorithms, so just refer to it as a deprecated shorthand for `diff-algorithm=patience`. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: do not imply using copy detection is desiredElijah Newren1-3/+3
Stating that the recursive strategy "currently cannot make use of detected copies" implies that this is a technical shortcoming of the current algorithm. I disagree with that. I don't see how copies could possibly be used in a sane fashion in a merge algorithm -- would we propagate changes in one file on one side of history to each copy of that file when merging? That makes no sense to me. I cannot think of anything else that would make sense either. Change the wording to simply state that we ignore any copies. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05merge-strategies.txt: update wording for the resolve strategyElijah Newren1-7/+6
It is probably helpful to cover the default merge strategy first, so move the text for the resolve strategy to later in the document. Further, the wording for "resolve" claimed that it was "considered generally safe and fast", which might imply in some readers minds that the same is not true of other strategies. Rather than adding this text to all the strategies, just remove it from this one. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05Documentation: edit awkward references to `git merge-recursive`Elijah Newren1-4/+5
A few places in the documentation referred to the "`recursive` strategy" using the phrase "`git merge-recursive`", suggesting that it was forking subprocesses to call a toplevel builtin. Perhaps that was relevant to when rebase was a shell script, but it seems like a rather indirect way to refer to the `recursive` strategy. Simplify the references. Acked-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11merge-strategies: fix typo "reflected to" to "reflected in"Dominic Jäger1-1/+1
Signed-off-by: Dominic Jäger <dominic.jaeger@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-08merge: add merge.renames config settingBen Peart1-4/+7
Add the ability to control rename detection for merge via a config setting. This setting behaves the same and defaults to the value of diff.renames but only applies to merge. Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Ben Peart <benpeart@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-21Merge branch 'dp/merge-strategy-doc-fix'Junio C Hamano1-1/+1
Doc fix. * dp/merge-strategy-doc-fix: Documentation/merge-strategies: typofix
2018-03-19Documentation/merge-strategies: typofixDavid Pursehouse1-1/+1
It's strategy, not stragegy. Signed-off-by: David Pursehouse <dpursehouse@collab.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27Merge branch 'jc/ignore-cr-at-eol'Junio C Hamano1-2/+3
The "diff" family of commands learned to ignore differences in carriage return at the end of line. * jc/ignore-cr-at-eol: diff: --ignore-cr-at-eol xdiff: reassign xpparm_t.flags bits
2017-11-08diff: --ignore-cr-at-eolJunio C Hamano1-2/+3
A new option --ignore-cr-at-eol tells the diff machinery to treat a carriage-return at the end of a (complete) line as if it does not exist. Just like other "--ignore-*" options to ignore various kinds of whitespace differences, this will help reviewing the real changes you made without getting distracted by spurious CRLF<->LF conversion made by your editor program. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> [jch: squashed in command line completion by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25merge-strategies: avoid implying that "-s theirs" existsJunio C Hamano1-1/+2
The description of `-Xours` merge option has a parenthetical note that tells the readers that it is very different from `-s ours`, which is correct, but the description of `-Xtheirs` that follows it carelessly says "this is the opposite of `ours`", giving a false impression that the readers also need to be warned that it is very different from `-s theirs`, which in reality does not even exist. Clarify it a bit to avoid misleading readers. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22merge-strategies.txt: fix typoFelipe Gonçalves Assis1-2/+2
Signed-off-by: Felipe Gonçalves Assis <felipegassis@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17merge-recursive: more consistent interfaceFelipe Gonçalves Assis1-4/+6
Add strategy option find-renames, following git-diff interface. This makes the option rename-threshold redundant. Signed-off-by: Felipe Gonçalves Assis <felipegassis@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17merge-recursive: option to disable renamesFelipe Gonçalves Assis1-0/+6
The recursive strategy turns on rename detection by default. Add a strategy option to disable rename detection even for exact renames. Signed-off-by: Felipe Gonçalves Assis <felipegassis@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-25Merge branch 'rr/doc-merge-strategies'Junio C Hamano1-2/+2
* rr/doc-merge-strategies: Documentation/merge-strategies: avoid hyphenated commands
2014-03-17Documentation/merge-strategies: avoid hyphenated commandsRamkumar Ramachandra1-2/+2
Replace git-pull and git-merge with the corresponding un-hyphenated versions. While at it, use ` to mark it up instead of '. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-11docs/merge-strategies: remove hyphen from mis-mergesAlbert L. Lash, IV1-1/+1
The term mismerges without hyphen is used a few other places in the documentation. Let's update this to be consistent. Signed-off-by: Albert L. Lash, IV <alash3@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09Documentation: document pitfalls with 3-way mergebrian m. carlson1-0/+8
Oftentimes people will make the same change in two branches, revert the change in one branch, and then be surprised when a merge reinstitutes that change when the branches are merged. Add an explanatory paragraph that explains that this occurs and the reason why, so people are not surprised. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05git-merge(1): document diff-algorithm option to merge-recursiveJohn Keeping1-0/+6
Commit 07924d4 (diff: Introduce --diff-algorithm command line option 2013-01-16) added diff-algorithm as a parameter to the recursive merge strategy but did not document it. Do so. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-08merge: teach -Xours/-Xtheirs to binary ll-merge driverJunio C Hamano1-1/+2
The (discouraged) -Xours/-Xtheirs modes of merge are supposed to give a quick and dirty way to come up with a random mixture of cleanly merged parts and punted conflict resolution to take contents from one side in conflicting parts. These options however were only passed down to the low level merge driver for text. Teach the built-in binary merge driver to notice them as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-26Merge branch 'kb/merge-recursive-rename-threshold'Junio C Hamano1-0/+4
* kb/merge-recursive-rename-threshold: diff: add synonyms for -M, -C, -B merge-recursive: option to specify rename threshold Conflicts: Documentation/diff-options.txt Documentation/merge-strategies.txt
2010-10-26Merge branch 'jf/merge-ignore-ws'Junio C Hamano1-0/+22
* jf/merge-ignore-ws: merge-recursive: options to ignore whitespace changes merge-recursive --patience ll-merge: replace flag argument with options struct merge-recursive: expose merge options for builtin merge
2010-10-08Use angles for placeholders consistentlyŠtěpán Němec1-1/+1
Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29merge-recursive: option to specify rename thresholdKevin Ballard1-0/+4
The recursive merge strategy turns on rename detection but leaves the rename threshold at the default. Add a strategy option to allow the user to specify a rename threshold to use. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-27merge-recursive: options to ignore whitespace changesJustin Frankel1-0/+15
Add support for merging with ignoring line endings (specifically --ignore-space-at-eol) when using recursive merging. This is as a strategy-option, so that you can do: git merge --strategy-option=ignore-space-at-eol <branch> and git rebase --strategy-option=ignore-space-at-eol <branch> This can be useful for coping with line-ending damage (Xcode 3.1 has a nasty habit of converting all CRLFs to LFs, and VC6 tends to just use CRLFs for inserted lines). The only option I need is ignore-space-at-eol, but while at it, include the other xdiff whitespace options (ignore-space-change, ignore-all-space), too. [jn: with documentation] Signed-off-by: Justin Frankel <justin@cockos.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-26merge-recursive --patienceJustin Frankel1-0/+7
Teach the merge-recursive strategy a --patience option to use the "patience diff" algorithm, which tends to improve results when cherry-picking a patch that reorders functions at the same time as refactoring them. To support this, struct merge_options and ll_merge_options gain an xdl_opts member, so programs can use arbitrary xdiff flags (think "XDF_IGNORE_WHITESPACE") in a git-aware merge. git merge and git rebase can be passed the -Xpatience option to use this. [jn: split from --ignore-space patch; with documentation] Signed-off-by: Justin Frankel <justin@cockos.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06merge-recursive --renormalizeJonathan Nieder1-0/+12
Teach "git merge-recursive" a --renormalize option to enable the merge.renormalize configuration. The --no-renormalize option can be used to override it in the negative. So in the future, you might be able to, e.g.: git checkout -m -Xrenormalize otherbranch or git revert -Xrenormalize otherpatch or git pull --rebase -Xrenormalize The bad part: merge.renormalize is still not honored for most commands. And it reveals lots of places that -X has not been plumbed in (so we get "git merge -Xrenormalize" but not much else). NEEDSWORK: tests Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-17Document that merge strategies can now take their own optionsJunio C Hamano1-1/+28
Also document the recently added -Xtheirs, -Xours and -Xsubtree[=path] options to the merge-recursive strategy. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15Documentation: clarify 'ours' merge strategyThomas Rast1-2/+3
Make it clear in the docs that the merge takes the tree of HEAD and ignores everything in the other branches. This should hopefully clear up confusion, usually caused by the user looking for a strategy that resolves all conflict hunks in favour of HEAD (which is completely different and currently not supported). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-25Grammar fixes to "merge" and "patch-id" docsWincent Colaiuta1-7/+7
Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-19Documentation/git-merge: document subtree strategy.Miklos Vajna1-0/+7
There was already some documentation about subtree under Documentation/howto but it was missing from git-merge manpage. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2005-12-08Documentation: recursive is the default strategy these days.Junio C Hamano1-5/+5
We still said resolve was the default in handful places. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-06Refactor merge strategies into separate includable file.Jon Loeliger1-0/+35
Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <junkio@cox.net>