git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Aguilar <davvid@gmail.com>
To: Kevin Bracey <kevin@bracey.fi>
Cc: git@vger.kernel.org, Ciaran Jessup <ciaranj@gmail.com>,
	Scott Chacon <schacon@gmail.com>,
	Alex Riesen <raa.lkml@gmail.com>
Subject: Re: [PATCH v3 1/3] mergetools/p4merge: swap LOCAL and REMOTE
Date: Tue, 12 Mar 2013 19:05:19 -0700	[thread overview]
Message-ID: <CAJDDKr7NJsmB3R_kYtZeocSZAz-kfP9k6GssZ+AM-qfPCTzrdg@mail.gmail.com> (raw)
In-Reply-To: <1363137142-18606-1-git-send-email-kevin@bracey.fi>

On Tue, Mar 12, 2013 at 6:12 PM, Kevin Bracey <kevin@bracey.fi> wrote:
> Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
> the incoming branch is now in the left-hand, blue triangle pane, and the
> current branch is in the right-hand, green circle pane.
>
> This change makes use of P4Merge consistent with its built-in help, its
> reference documentation, and Perforce itself. But most importantly, it
> makes merge results clearer. P4Merge is not totally symmetrical between
> left and right; despite changing a few text labels from "theirs/ours" to
> "left/right" when invoked manually, it still retains its original
> Perforce "theirs/ours" viewpoint.
>
> Most obviously, in the result pane P4Merge shows changes that are common
> to both branches in green. This is on the basis of the current branch
> being green, as it is when invoked from Perforce; it means that lines in
> the result are blue if and only if they are being changed by the merge,
> making the resulting diff clearer.
>
> Note that P4Merge now shows "ours" on the right for both diff and merge,
> unlike other diff/mergetools, which always have REMOTE on the right.
> But observe that REMOTE is the working tree (ie "ours") for a diff,
> while it's another branch (ie "theirs") for a merge.
>
> Ours and theirs are reversed for a rebase - see "git help rebase".
> However, this does produce the desired "show the results of this commit"
> effect in P4Merge - changes that remain in the rebased commit (in your
> branch, but not in the new base) appear in blue; changes that do not
> appear in the rebased commit (from the new base, or common to both) are
> in green. If Perforce had rebase, they'd probably not swap ours/theirs,
> but make P4Merge show common changes in blue, picking out our changes in
> green. We can't do that, so this is next best.
>
> Signed-off-by: Kevin Bracey <kevin@bracey.fi>
> ---

This seems sensible to apply.  The commit message is a bit long,
but I think it's justified since this is exactly the kind of thing
I would tend to forget after enough time has passed.

Ditto on the create_virtual_base patch.  Your latest patch
addressed Junio's note about making it take 2 args.

FWIW, please feel free to add:

Reviewed-by: David Aguilar <davvid@gmail.com>

Thanks.

>  mergetools/p4merge | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mergetools/p4merge b/mergetools/p4merge
> index 8a36916..46b3a5a 100644
> --- a/mergetools/p4merge
> +++ b/mergetools/p4merge
> @@ -22,7 +22,7 @@ diff_cmd () {
>  merge_cmd () {
>         touch "$BACKUP"
>         $base_present || >"$BASE"
> -       "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
> +       "$merge_tool_path" "$BASE" "$REMOTE" "$LOCAL" "$MERGED"
>         check_unchanged
>  }
>
> --
> 1.8.2.rc3.7.g1100d09.dirty
>



-- 
David

  parent reply	other threads:[~2013-03-13  2:05 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06 20:32 [PATCH 0/2] Improve P4Merge mergetool invocation Kevin Bracey
2013-03-06 20:32 ` [PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool Kevin Bracey
2013-03-07  0:36   ` Junio C Hamano
2013-03-07  6:16     ` Kevin Bracey
2013-03-07  7:23       ` Junio C Hamano
2013-03-07 17:14         ` Kevin Bracey
2013-03-07 19:10           ` Junio C Hamano
2013-03-07 19:50             ` David Aguilar
2013-03-07 20:31               ` Junio C Hamano
2013-03-06 20:32 ` [PATCH 2/2] p4merge: create a virtual base if none available Kevin Bracey
2013-03-07  2:23   ` David Aguilar
2013-03-07  6:28     ` Kevin Bracey
2013-03-07  7:25     ` Junio C Hamano
2013-03-07  3:33   ` David Aguilar
2013-03-09 19:20 ` [PATCH v2 0/3] Improve P4Merge mergetool invocation Kevin Bracey
2013-03-09 19:20   ` [PATCH v2 1/3] mergetools/p4merge: swap LOCAL and REMOTE Kevin Bracey
2013-03-09 19:20   ` [PATCH v2 2/3] mergetools/p4merge: create a base if none available Kevin Bracey
2013-03-10  4:55     ` Junio C Hamano
2013-03-09 19:21   ` [PATCH v2 3/3] git-merge-one-file: revise merge error reporting Kevin Bracey
2013-03-13  1:12 ` [PATCH v3 1/3] mergetools/p4merge: swap LOCAL and REMOTE Kevin Bracey
2013-03-13  1:12   ` [PATCH v3 2/3] mergetools/p4merge: create a base if none available Kevin Bracey
2013-03-13  1:12   ` [PATCH v3 3/3] git-merge-one-file: revise merge error reporting Kevin Bracey
2013-03-13  9:03     ` David Aguilar
2013-03-24 12:26       ` [PATCH v2 0/3] git-merge-one-file " Kevin Bracey
2013-03-24 12:26         ` [PATCH v2 1/3] git-merge-one-file: style cleanup Kevin Bracey
2013-03-24 12:26         ` [PATCH v2 2/3] git-merge-one-file: send "ERROR:" messages to stderr Kevin Bracey
2013-03-24 12:26         ` [PATCH v2 3/3] git-merge-one-file: revise merge error reporting Kevin Bracey
2013-03-25 17:04           ` Junio C Hamano
2013-03-25 17:17             ` Junio C Hamano
2013-03-25 17:20               ` Junio C Hamano
2013-03-25 19:24               ` Eric Sunshine
2013-03-13 17:57     ` [PATCH v3 " Junio C Hamano
2013-03-14  6:27       ` Kevin Bracey
2013-03-14 14:56         ` Junio C Hamano
2013-03-14 17:31           ` Kevin Bracey
2013-03-14 17:39             ` Kevin Bracey
2013-03-13  2:05   ` David Aguilar [this message]
2013-03-24 11:54   ` [PATCH v4 1/2] mergetools/p4merge: swap LOCAL and REMOTE Kevin Bracey
2013-03-24 11:54     ` [PATCH v4 2/2] mergetools/p4merge: create a base if none available Kevin Bracey
2013-03-25 17:47       ` Junio C Hamano

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=CAJDDKr7NJsmB3R_kYtZeocSZAz-kfP9k6GssZ+AM-qfPCTzrdg@mail.gmail.com \
    --to=davvid@gmail.com \
    --cc=ciaranj@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kevin@bracey.fi \
    --cc=raa.lkml@gmail.com \
    --cc=schacon@gmail.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).