git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan del Strother <maillist@steelskies.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Offer to print changes while running git-mergetool
Date: Fri, 6 Feb 2009 19:08:47 +0000	[thread overview]
Message-ID: <57518fd10902061108k6a7691c5r13b2782baf3bfde3@mail.gmail.com> (raw)
In-Reply-To: <7vocxf5ufu.fsf@gitster.siamese.dyndns.org>

On Fri, Feb 6, 2009 at 5:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan del Strother <maillist@steelskies.com> writes:
>
>> 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.
>

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?

  reply	other threads:[~2009-02-06 19:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-06 14:32 [PATCH] Offer to print changes while running git-mergetool Jonathan del Strother
2009-02-06 14:41 ` Jonathan del Strother
2009-02-06 17:47   ` Junio C Hamano
2009-02-06 19:08     ` Jonathan del Strother [this message]
2009-02-07  0:21       ` Junio C Hamano
2009-02-07  8:11 ` Junio C Hamano
2009-02-07 12:01   ` Jonathan del Strother
2009-02-08  1:24     ` Charles Bailey
2009-02-08 11:43       ` Jonathan del Strother
2009-02-08 12:38         ` Charles Bailey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57518fd10902061108k6a7691c5r13b2782baf3bfde3@mail.gmail.com \
    --to=maillist@steelskies.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).