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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 6, 2009, 17:47 UTC
Message-ID: <7vocxf5ufu.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <57518fd10902060641pa789ffbjceccbf013864e0a5@mail.gmail.com>

Jonathan del Strother <maillist@steelskies.com> writes:

Show 7 quoted lines

> On Fri, Feb 6, 2009 at 2:32 PM, Jonathan del Strother
> <jon.delStrother@bestbefore.tv> wrote:
>> 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>'
>
> Just discovered that this doesn't work so well when resolving merges
> resulting from "git stash apply" - it produces "fatal: --merge without
> MERGE_HEAD".  Should git-stash be setting MERGE_HEAD in this case,

No no no, please absolutely don't. MERGE_HEAD is an instruction to the eventual commit to create a merge commit and use the commits recorded there as other parents when it does so. You do *NOT* want to end up with a merge with random state after unstashing. None among cherry-pick, rebase, checkout -m (branch switching), nor am -3 should.

I'd suggest making the new action conditionally available, by using the presense of MERGE_HEAD as a cue.

The thing is, these commands that can potentially end in conflict operate only at the tree level, and not at the level of commit ancestry graph. "log --merge" is all about following the commit ancestry graph, and for conflicts left by these commands it is not a useful way to review.