Re: Command-line interface thoughts

[Jay Soffian <jaysoffian@gmail.com>]

On Thu, Jun 9, 2011 at 1:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> 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.