Jonathan del Strother <maillist@xxxxxxxxxxxxxx> writes: > On Fri, Feb 6, 2009 at 2:32 PM, Jonathan del Strother > <jon.delStrother@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
