Subject: Re: [PATCH] Offer to print changes while running git-mergetool

From: Charles Bailey <[email-masked]>
Date: Sun, 08 Feb 2009 12:38:55 +0000

Jonathan del Strother wrote:
>> 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.

My point wasn't that we should use gitk instead, I was just trying to
illustrate that there may be a whole raft of other commands or
activities that a user might want to run to help them with a merge so
why should we hard wire any one of them into mergetool?

The other doubt that I've since had about this patch is this. Is just
before running the merge tool the best place to offer to show the log?

In my usual workflows (not necessarily the best!), I usually want to
fire up the merge tool as quickly as possible to get the merge
resolutions done.

Only once I'm in the mergetool do I realise that this one's a bit
complex and I might need to consult the logs to help me resolve this one.

But now, mergetool is blocked waiting for the merge tool to finish. If I
abort the merge it's going to offer me the option to abort completely or
carry on with the next file. (Perhaps "try again" could be a future
direction that mergetool might offer, but it doesn't at the moment.)

I'm far more likely to want to consult the logs in a different terminal
(or gui) with the merge tool still running, especially if I've already
merged some of the easy chunks and have only hit difficulties later on
in the merge.

Charles.