Recently I enabled diff3 and it's much easier to resolve conflict now.
Previously in some cases I had to check the log to see why people did this and that to do the merge. But with diff3 the information is displayed all in one place
<<<<<<< HEAD THIS IS USEFUL ||||||| merged common ancestors This is useful ======= This is really useful >>>>>>> c2392943.....
From that we can easily see that the result should be "THIS IS REALLY USEFUL"
I wonder if there is any downside to diff3? Why it is not the default behavior of git?
One merge tool that git uses is called diff3 or sometimes kdiff3 , which, as you can guess, produces a merged output of 3 different files that share a common ancestor.
The git-merge docs explain quite well how this will affect your merge: 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.
You can use the git reset --merge command. You can also use the git merge --abort command.
For other readers (and from this article):
git has an option to display merge conflicts in
diff3
format (by default it only displays the two files to be merged). You can enable it like so:
git config --global merge.conflictstyle diff3
There's really no reason you shouldn't enable the diff3 style, because you frequently need the ancestor to determine what the correct merge is.
This was introduced fairly early (2008), and I suppose it isn't the default, because a default Unix diff
isn't display as a 3-way diff.
With Git 2.35, you also have zdiff3
("zealous diff3").
As mentioned in this thread, if you want to run this command without setting the config, so that you can switch between normal diffs and diff3s easily, this is possible in one specific case:
If a conflict is marked in the index (i.e., the state you are in after a conflicted merge, but before you mark a path as resolved), you can do:
git checkout --conflict=diff3 <path...>
Note that that is actually checking out the index contents into the working tree, so any edits you may have made to the conflicted working tree copy will be overwritten.
Note that the |||||| merged common ancestors
will evolve with git 2.24 (Q4 2019)
See commit b657047 (07 Oct 2019), commit 8e4ec33 (01 Oct 2019), and commit 4615a8c, commit 45ef16f, commit f3081da, commit 5bf7e57, commit e95e481, commit a779fb8, commit 8599ab4, commit 7c0a6c8, commit c749ab1, commit bab5687, commit ff1bfa2, commit 4d7101e, commit 724dd76, commit 345480d, commit b4db8a2, commit 98a1d3d, commit 9822175, commit 10f751c (17 Aug 2019) by Elijah Newren (newren
).
(Merged by Junio C Hamano -- gitster
-- in commit 280bd44, 15 Oct 2019)
merge-recursive
: provide a better label for diff3 common ancestorSigned-off-by: Elijah Newren
In commit 7ca56aa07619 ("
merge-recursive
: add a label for ancestor", 2010-03-20, Git v1.7.1-rc0 -- merge), a label was added for the '||||||
' line to make it have the more informative heading '|||||| merged common ancestors
', with the statement:It would be nicer to use a more informative label.
Perhaps someone will provide one some day.This chosen label was perfectly reasonable when recursiveness kicks in, i.e. when there are multiple merge bases.
(I can't think of a better label in such cases.)
But it is actually somewhat misleading when there is a unique merge base or no merge base.
Change this based on the number of merge bases:
>=2: "merged common ancestors" 1: <abbreviated commit hash> 0: "<empty tree>"
Tests have also been added to check that we get the right ancestor name for each of the three cases.
With Git 2.25 (Q1 2020), "git apply --3way
" learned to honor merge.conflictStyle
configuration variable, like merges would.
See commit 091489d, commit aa76ae4, commit 9580620, commit b006968, commit fa87b81 (23 Oct 2019) by Denton Liu (Denton-L
).
(Merged by Junio C Hamano -- gitster
-- in commit eff313f, 10 Nov 2019)
apply
: respect merge.conflictStyle in --3waySigned-off-by: Denton Liu
Before, when doing a 3-way merge, the
merge.conflictStyle
option was not respected and the "merge
" style was always used, even if "diff3
" was specified.Call
git_xmerge_config()
at the end ofgit_apply_config()
so that the merge.conflictStyle config is read.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With