Re: Common ancestor in merge diffs?

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 26 Jan 2009, Daniel Barkalow wrote:
> 
> That is really nice, and quite handy. I ended up getting approximately 
> that effect with blame and show, but gitk is much easier. For some reason, 
> I never think of the graphical tools.

You can do the same thing on the command-line with just doing

	git log --merge [filename]

but when doing conflict resolution you often do care (deeply) about the 
way the commits hang together, so the graphical tools really do end up 
giving you fundamentally interesting information that is hard to show in 
any readable way with just plain text.

[ Yeah, there's "--graph", but it really loses out on the whole 
  readability thing ]

> Is there an easy way of focusing on the changes that end up in a 
> particular conflict? Half of the work was finding the right commit and 
> finding the right part of the diff.

This is where the command line tools really help. What I do is to just 
fire up that "gitk" and 90% of the time the thing is clear from that. But 
_if_ it then is complex, and has a ton of changes to the same file that 
really aren't that interesting, doing a 

	git log --merge -S'interesting-part-goes-here' [filename]

in another window tends to be a good idea. That way you get the commits 
that just touch that string, and you can do the whole 'goto-SHA1' in the 
gitk window to see them there.

Sometimes, "git blame -C " is also a good tool to have around. You seem to 
have found it already. One usage case is

	git blame -C $(git merge-base HEAD MERGE_HEAD).. filename

which then high-lights the lines changed from the merge-base to the HEAD 
(change it to "..MERGE_HEAD" to see what changed to MERGE_HEAD), but quite 
frankly, I tend to use "git blame" more as a tool _after_ the merge, when 
I noticed that I merged things wrong and go back and try to figure out 
what caused the problem.

		Linus