tags:

views:

81

answers:

2

I've read this question and the answers, but what isn't clear to me is WHO creates the "changes that do not appear in any parent".

Is it the git merge algorithm screwing up?

Or is it because the user has to manually adjust the conflicts to get the thing to build, introducing new code which wasn't in either parent?

A: 

It happens when a developer has a merge conflict that he must manually fix, and in doing so, he changes code that is not related to the merge conflict itself. Git's merging algorithms will not insert unrelated, "evil" code changes by itself.

mipadi
To be nit-picky, you could add code that was *related* to the merge conflict, without it being code from either parent, and you'd have a merge that was at least moderately evil.
Jefromi
+3  A: 

It is explained in the first comment of the correct answer. You merge without doing a commit (either through conflict or --no-commit) and then add additional changes to the merge before committing.

Note, resolving a merge conflict is not evil, you simply pick code which exists in one or both sides of the conflict. If you add some code which does not exist in either side, you have now turned the merge evil.

Justin
Sometimes the only way to properly resolve a conflict is to add code which doesn't exist in either parent, of course, and while that merge resolution would be evil, I'd say it's more lawful evil, as opposed to a "chaotic evil" merge adding code which has nothing to do with the contents of the merge.
Jefromi
@Jefromi, that's kind of what my question was working towards. I didn't see how you could reconcile "Don't break the build" and avoiding evil merges.
Benjol
@Benjol: Well, sometimes all you have to do is choose the line from one parent over the analogous line from the other - but you're right, most of the time in the real world you have to do more.
Jefromi