On Fri, Feb 6, 2009 at 5:47 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.
>
Maybe I'm misunderstanding the issue, but it seems like showing the
conflicted changes somehow could still be useful. eg If I've made
changes on branch A, stash, switch to branch B, apply the stash and
get conflicts, I'd still like to see the commits that produced those
conflicts.
Obviously for a stash 'merge', one side of the merge isn't that
interesting : it's just going to be all the stuff from my working copy
before it was stashed. But wouldn't the other side of the merge (ie
changes made on branch B since A & B diverged) produce useful
information?
Off the top of my head, I guess I want something like "git log -p
^stash HEAD", but obviously that doesn't work when dealing with, say,
"git stash apply stash@{2}".
Or is this not workable for some reason I'm not thinking of?
--
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
