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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
