3

I have a recurrent problem that happens sometimes when I merge two PHP classes, in which both branches have added a function to this class. Lets say I have this situation:

Branch A

class MyClass {
   /* ... previous content ... */

   public function newFunctionA() {
      /* ... Content for function A ... */
   }
}

Branch B

class MyClass {
   /* ... previous content ... */

   public function newFunctionB() {
      /* ... Content for function B ... */
   }
}

When I merge Branch B into Branch A I get the following:

class MyClass {
   /* ... previous content ... */

   <<<<<<< HEAD
   public function newFunctionA() {
      /* ... Content for function A ... */
   =======
   public function newFunctionB() {
      /* ... Content for function B ... */
   }

   >>>>>>> branchB
}

It includes the two functions, but for some reason it omits the closing braces (}) for the first function. I known its easily solved but accepting the two contents and inserting the braces myself, but I wonder is there is anything I can change in my coding style to facilitate git's merge process and prevent these conflicts?

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Marlon
  • 1,719
  • 3
  • 20
  • 42

1 Answers1

3

The answer is maybe no, but maybe yes

We can't be sure because there's something you're not showing us (and Git isn't showing you ). Specifically, you're missing the third input here, which is the merge base commit.

If we could see the actual conflict, we could say more for certain. To see the actual conflict, we'll need to see what shows up in the file if you set merge.conflictStyle to diff3.

What's going on

When Git combines work, it's looking not at just the two branch-tip commits. That is, it's not comparing:

class MyClass {
   /* ... previous content ... */

   public function newFunctionA() {
      /* ... Content for function A ... */
   }
}

vs

class MyClass {
   /* ... previous content ... */

   public function newFunctionB() {
      /* ... Content for function B ... */
   }
}

Instead, it's making two diffs. One compares:

class MyClass {
   /* ... previous content ... */
}

to:

class MyClass {
   /* ... previous content ... */

   public function newFunctionA() {
      /* ... Content for function A ... */
   }
}

The diff between these two is, e.g., instructions of the form:

  • at line 42, add a blank line
  • at line 43, addpublic function newFunctionA() {
  • at line 44, add a blank line
  • at line 45, add ...
  • at line 52, add }

Because of Git's diff format, all "add line" blocks get clumped together, but any matching lines—such as blank lines—in the two input files may cause a second "add some stuff" block.

Then, separately, Git is comparing:

class MyClass {
   /* ... previous content ... */
}

(this is the same version of the file that is on the left in the first comparison) to:

class MyClass {
   /* ... previous content ... */

   public function newFunctionB() {
      /* ... Content for function B ... */
   }
}

This, too, generates a series of change instructions. Any lines that match up on the left side (the original) with lines on the right side (the new stuff) may be considered "the same".

Git then tries to combine the two sets of instructions.

What we need to see is the two sets of instructions, rather than the conflict itself. In particular, if the instructions are pretty similar—as they are in your case—Git by default goes ahead and combines the parts it can, and leaves conflict markers only around the parts it can't. So we don't know where the conflicts really start and end.

When using diff3 as the conflict style, Git leaves in the full conflict, showing the merge base version in between.

More information and some examples

Git 2.11 added a new heuristic for git diff. (It looks to me like this heuristic is never used internally by git merge; if it were, I think you'd be more likely to get what you want. But I can't be sure about this.) See this answer from VonC. For more detail, see commit 433860f3d0beb0c6f205290bd16cda413148f098 in the Git source code.

The TL;DR summary is that the heuristic changes the git diff output from:

--- a/9c572b21dd090a1e5c5bb397053bf8043ffe7fb4:git-send-email.perl
+++ b/6dcfa306f2b67b733a7eb2d7ded1bc9987809edb:git-send-email.perl
@@ -231,6 +231,9 @@ if (!defined $initial_reply_to && $prompting) {
 }

 if (!$smtp_server) {
+       $smtp_server = $repo->config('sendemail.smtpserver');
+}
+if (!$smtp_server) {
        foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
                if (-x $_) {
                        $smtp_server = $_;

(note how diff has synced up on the "wrong" set of lines) to:

--- a/9c572b21dd090a1e5c5bb397053bf8043ffe7fb4:git-send-email.perl
+++ b/6dcfa306f2b67b733a7eb2d7ded1bc9987809edb:git-send-email.perl
@@ -230,6 +230,9 @@ if (!defined $initial_reply_to && $prompting) {
        $initial_reply_to =~ s/(^\s+|\s+$)//g;
 }

+if (!$smtp_server) {
+       $smtp_server = $repo->config('sendemail.smtpserver');
+}
 if (!$smtp_server) {
        foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
                if (-x $_) {

(note how it's now on the "right" set of lines, to human eyes). The two diffs are equivalent in terms of the change made the the file, but we prefer the second one. Moreover, if git merge is working to combine changes, we'd prefer git merge to see the second one.

Note that this is just a heuristic, so whether it works for your particular pair of changes is another question. Running the two git diff operations yourself (with the heuristic turned on, as it is by default in modern Git, and with it off with --no-indent-heuristic) will tell you whether it does.

torek
  • 448,244
  • 59
  • 642
  • 775