Merge/diff tool that can show authors (supports blame or annotate) in files under version control

Question

When merging files it will be helpful (as for me) to show an author of each line. Is there any diff or merge tool supporting that?

Preponderate

Answer 1

The bundled gitk tool is not really a merge tool, but it shows conflicted lines with red and blue and "+"'s in front, and you can Rightclick->"Show origin of this line" on any of them, to go to the commit which introduced the line:

You can run your mergetool, or just a text editor with diffmarks in parallel

Nubia

Answer 2

So what you really want is a tool that can easily identify your changes relative to other's changes in a merge conflict, rather actually identify the author of each line (which would be a mean to achieve that), right?

If I understood you correctly, I have some relatively good news: It can be done with git + kdiff3. For merging you can just use git mergetool (which you can configure to use kdiff3). But it is not supported natively if you get a merge conflict when doing interactive rebase, so for that some manual scripting is required.

Instead of making up my own simple merge conflict example, I will use http://www.gitguys.com/topics/merging-with-a-conflict-conflicts-and-resolutions/ as an basis. Follow that page to git merge test. From after the merge command I diverge a bit from that example by running different commands (but basically doing the same job). I'll do all the manuall steps first.

So we have a merge conflict and git has inserted content from both contributing sources into the file in this <<<<<<<...>>>>>>> format, which I really do not like at all and never consider even looking at it. Instead I use my favourite merge tool, kdiff3.

First we need to find which versions that are involved.

$ git ls-files -u
100644 b0ed415d15862ac5582b51e4de65528e86934cd2 1       README
100644 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 2       README
100644 9585db7d9c2d9ca05075f67a878f2554886d7b1a 3       README
$

Basted that information we can perform a three way merge:

$ git cat-file blob b0ed415d15862ac5582b51e4de65528e86934cd2 > v1
$ git cat-file blob 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 > v2
$ git cat-file blob 9585db7d9c2d9ca05075f67a878f2554886d7b1a > v3
$ kdiff3 -o merge_result v1 v2 v3 &
[2] 18394
$

Which gives the following view where you can select from which ancestor you want to merge from.

Afterwords (if you are satisfied with the merge result) you need to

$ rm v1 v2 v3
$ mv merge_result README
$ git add README

All the manual steps above are done automatically with git mergetool. So why showing all that then? Well, because if you get a corresponding conflict during git rebase -i, then it has to be done that way (before running git rebase --continue).

In this small example there is only one conflict line, so it does not show the more typical case where a lot of lines are automatically resolved, leaving you to just manually resolve the ones that was not done automatically. A more real life example might look more like the following:

Notice that in the merge result you now clearly see the origin of the C lines that were automatically resolved. I think this is sort of what you were asking for when asking for getting the author for each line, right? That information is completely absent in the <<<<<<<...>>>>>>> text (and it is difficult/impossible to spot that you should update the printed string in the hello function).

I cannot recommend kdiff3 highly enough. Using a graphical merge tool like that compared to some lines from both sources mixed inline in the file is like using an excavator versus a spade.

Mchenry

This isn't what they were asking. They want to know which commit caused the conflict. In other words show the git blame for the lines that were edited to cause a conflict. KDiff3 doesn't show that unfortunately. – Dysphagia

Answer 3

No. And, I think, never will be - when we merge, we think about content, not authorship

Undersize

I agree, but in some cases it may be useful. For example, there is a source file in which I add some code. Let the file was changed on the repo while I was making edits. So, I need to merge it, but all I need is to add only my edits. It will be easier to locate them when they are signed. – Preponderate

@Preponderate - in this case you just see at "my" file in merge-window (and merge tool have to define separate windows titles) – Undersize

When merging conflicts I almost always adjust my level of scrutiny depending on seniority of the author. This is not ideal, but time constraints often require that. – Weatherbound

When viewing differences in content, being able to view the author and the date of the different versions is essential. Unless you know all the code changes made by other developers perfectly, I don't understand how you don't consider the author and date of the two versions as being vital to your merge decision. – Ringster

It's not so much about authorship as it is heritage of the content in question: trying to answer the question "what motivated each respective change that is in conflict?" The author is likely of less interest than the when the change was made, what other changes were part of the commit containing the change, and the like. – Naquin