From: Jay Soffian Date: Thu, 09 Jun 2011 18:20:29 GMT Subject: Re: Command-line interface thoughts Message-ID: In-Reply-To: <7vd3imykj1.fsf@alter.siamese.dyndns.org> On Thu, Jun 9, 2011 at 1:36 PM, Junio C Hamano wrote: > Jay Soffian 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 ... >  $ 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 [...] Now that's one I haven't used before. I usually use log ..MERGE_HEAD and log MERGE_HEAD.. on the paths. j.