Menu
"man gitglossary" contains this definition of an evil merge:
An evil merge is a merge that introduces changes that do not appear in any parent.
I am not sure I understand the point the authors are trying to get at. Why is it evil ?
588
Git merging is a great way to go because it is considered a non-destructive operation. This is because the existing branches are not changed in any way. It also helps you avoid the potential pitfalls that come with rebasing, which we will take a look at below.
Git merging combines sequences of commits into one unified history of commits. There are two main ways Git will merge: Fast Forward and Three way. Git can automatically merge commits unless there are changes that conflict in both commit sequences.
The most commonly used strategies are Fast Forward Merge and Recursive Merge. In this most commonly used merge strategy, history is just one straight line. When you create a branch, make some commits in that branch, the time you're ready to merge, there is no new merge on the master.
For simple text files, Git uses an approach known as the longest common subsequence algorithm to perform merges and to detect merge conflicts. In its simplest form, Git find the longest set of lines in common between your changed file and the common ancestor.
Because it's putting things in the code that no one ever asked to be there. As if you had this code:
$foo = bar; $baz = qxx; and this change:
$foo = bar; $foo++; $baz = qxx; got merged with this change:
$foo = bar; $foo--; $baz = qxx; in a fashion that somehow produced:
$foo = bar; $foo++; $foo--; --$baz; $baz = qxx; Clearly, this is evil.
I would guess that it's of enough concern to be in man gitglossary because the more involved your merging algorithms are, the more likely it is that they will produce such a thing.
167
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
