7

I'm trying to figure out whether a merge conflict was responsible for a bug, but I'm having difficulty because I'm not clear on how conflict resolution affects git blame.

Let's say I have a file in master:

a();
b();
c();

I modify it in master:

a();
d();
c();

but so does a co-worker, and they modify it differently, in a separate branch which they then merge in to master:

a();
e();
c();

Can resolving that conflict affect the blame? In other words, if my co-worker resolves the conflict by going with my version:

a();
d();
c();

and I git blame the d(); line, who will be blamed: me or my co-worker?

Similarly, let's say git got confused and thought both the first and second lines were conflicted:

<<<<
a();
d();
====
a();
e();
>>>>

If my co-worker resolves the conflict with their version:

a();
e();
c();

and I git blame the a(); line, will I (the line's original author) get the blame, or will my co-worker (who "touched" it last, even though they didn't change it) get the blame?

Enrico Campidoglio
  • 56,676
  • 12
  • 126
  • 154
machineghost
  • 33,529
  • 30
  • 159
  • 234
  • 2
    You could probably create a test repository to test this out. Create a file in master. Create a new branch and change it. Switch back to master and change it. Merge and resolve the conflict and do a `git blame` on the file. In fact, you wouldn't even need a git server to host the repository. – Greg Burghardt Sep 24 '15 at 21:02
  • I haven't tested this, but I expect that `blame` would cite whoever *resolved* the conflict, since the resolution is then followed by `git add`. – Kyle Strand Sep 24 '15 at 22:26

1 Answers1

9

tl;dr

If you run git blame on a merged file you are going to see the original author of each line, regardless of who did the merge commit. This means that if your co-worker decided to resolve the conflict using your version of the line, your name will be shown next to it.

Reconstructing the history of a file

In Git each commit holds two key pieces of information:

  • A reference to a snapshot of your working directory at the time of the commit.
  • A reference to the commit that came before it, aka its parent.

Given these two facts Git can reconstruct the history of changes occurred in a file by walking backwards from a given commit, generating at each step a diff between the current version of the file and its previous one.

This is exactly what git blame does. When you do git blame on a file, Git will reconstruct the history of the file on a line by line basis, showing you the author of the commit that introduced (i.e. added) each line.

Merge commits

A merge commit holds a reference to two parents:

  • The commit referenced by the branch you merged into, aka the left side.
  • The commit referenced by the branch you merged, aka the right side.

The snapshot contains all the changes from each side combined.

If you do a git blame on a merge commit, Git will walk two lines of history, one for each of the parent commits. Once Git reaches the commit whose snapshot added a certain line, it will show that commit's author next to the line.

Adding new lines when resolving a conflict

If a new line – that is a line that doesn't belong to either side of the merge – was added as part of a conflict resolution, that line would belong to the snapshot referenced by the merge commit itself. In that case git blame will report the author of the merge commit for that line.

Enrico Campidoglio
  • 56,676
  • 12
  • 126
  • 154