From: Jonathan del Strother <jon.delstrother@bestbefore.tv>
Date: Sun, 08 Feb 2009 11:43:45 GMT
Subject: Re: [PATCH] Offer to print changes while running git-mergetool
Message-ID: <57518fd10902080343p47e30330ufdf2ece909ea0bd9@mail.gmail.com>
In-Reply-To: <498E3456.1080509@hashpling.org>

On 2/8/09, Charles Bailey <charles@hashpling.org> wrote:
> Jonathan del Strother wrote:
>> On Sat, Feb 7, 2009 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Jonathan del Strother <jon.delStrother@bestbefore.tv> writes:
>>>
>>>> Add a "Show changes" option to each prompt in mergetool. This prints the
>>>> conflicted changes on the current file, using 'git log -p --merge
>>>> <file>'
>>> I think the patch should look like this, given the recent conversation I
>>> had with you.  It seems that the script thinks the unit of indentation is
>>> 4-places, and case arms are indented from case/esac (neither of which is
>>> the standard git shell script convention), and I tried to match that
>>> style
>>> used in the existing code.
>>>
>>> No, I didn't test it.
>>>
>>> Charles volunteered to take over mergetool, so he is on the Cc: list.
>
> At the moment, I'm slightly cool towards this patch, but perhaps I don't
>  really understand the underlying issue. I understand wanting to check
> something (logs) in the middle of a mergetool run but I can't say that
> I've ever wanted to specifically run 'git log -p --merge'. Perhaps some
> users of mergetool - being visual people - would more naturally reach
> for gitk?
>
> Given that mergetool picks up from where it left off when run a second
> time, what does this patch offer over Ctrl-c, run log tool of your
> choice, re-run mergetool? Or just running git log in a different
> terminal instance?
>

A large part of my motivation behind this patch was basically
education - my team (and myself) have made poor merge decisions in the
past, largely due to not being aware of a tool like "git log --merge".
The patch was attempting to get inexperienced users to make better use
of such tools. I certainly wouldn't be averse to using gitk instead.