CODEWITHSUNDEEP
gitmerge
Michael L.
Michael L.

Reputation: 618

git merge does not produce conflict on code deletion

A co-worker and I are in the planning & testing stages for converting our development group to using git as the source control tool. We have established a workflow that emphasizes code safety and workflow simplicity. However, in testing different merge cases, I have found situations where git merge will automatically merge differences when it seems a conflict and manual merge would be the safer option.

Example: Branch origin/master contains a single script file which has functions foo() and bar() as commit C1. Two users each checkout C1 locally on their machines to make changes. User1 adds function baz() and removes function foo(). He does a fast-forward merge and pushes his changes back to origin/master as C2. User2 modifies bar() so it calls foo() and commits his changes to C3. He runs a fetch and merge to bring in any changes from origin/master and git performs a recursive merge into C4 that results in a file that contains only bar() and baz() where bar() is now broken because it calls foo() which no longer exists.

Question: I realize I can setup a custom merge driver to automatically cause a conflict in these situations (and I've done so) in order to force manual merges. However, this seems to be such a fundamental issue with git that I'm surprised nobody else is discussing it. Am I missing something or is a custom merge driver the best way to handle this?

One last thing, I realize there are tools available to fix this after-the-fact, but fixing during merge seems the cleanest and most straight-forward method.

edit: I realize git can't detect broken code, but it can detect that a file was changed in both branches from the nearest common ancestor and I would think producing a conflict is safer than automatically merging. My custom merge driver accomplishes this, but I wanted to see if there was a Better Way(TM).

Upvotes: 2

Views: 539

Answers (1)

Karl Bielefeldt
Karl Bielefeldt

Reputation: 49108

This problem isn't unique to git. Every version control system I'm aware of manages textual conflicts, not semantic conflicts. In other words, git can detect if two people change the same line of code. The only way to detect the kind of conflicts you are talking about would be to essentially compile the code as part of the conflict detection process. Note that's not an entirely unfeasible thing to do, it's just that no one has gotten around to it yet.

For most teams, this situation does not come up very often. If it happens to you a lot, you might want to look at the coupling of your design, or your communication with your teammate about how work is divided.

Upvotes: 4

Related Questions