On Thu, Jun 9, 2011 at 1:36 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jay Soffian <jaysoffian@xxxxxxxxx> writes: > >> In fact, my first step after a conflicted merge is: >> >> Â $ git tag -f ours HEAD >> Â $ git tag -f theirs MERGE_HEAD >> Â $ git tag -f base $(git merge-base HEAD MERGE_HEAD) > > That looks like quite a convoluted set-up, I would think, than > necessary. You only need to remember these: My merges are fairly complex, involving a code base of 20k+ files with merges bringing several hundred commits at a time. So, they require lots of amending after conflict resolution to get into shape, where I often have to look at either side of the merge. I prefer to tag at the time of the merge so that I can use ours, theirs, and before and after the merge (otherwise it's HEAD MERGE_HEAD vs HEAD^ and HEAD^2). > Â# what does the result look if I said "commit -a" now? > Â$ git diff HEAD I never use commit -a. > Â# I want to also see comparison with the original > Â$ git checkout --conflict=diff3 <conflicted paths>... > Â$ git diff I have merge.conflictstyle diff3 in my .gitconfig. > Â# What did they do since they forked from my history? > Â$ git diff ...MERGE_HEAD > > Â# What did I do since I forked from them? > Â$ git diff MERGE_HEAD... Sure, I already suggested that, but if I want to do the same after the merge I can use the tags I've already set up. > Â# I want step-by-step explanation of how these paths were touched > Â$ git log -p --left-right --merge [<conflicted paths>...] Now that's one I haven't used before. I usually use log ..MERGE_HEAD and log MERGE_HEAD.. on the paths. j. -- 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