All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j.sixt@viscovery.net>
To: Jon Seymour <jon.seymour@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>, spearce@spearce.org
Subject: Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the 	case of conflicts.
Date: Wed, 31 Mar 2010 09:20:00 +0200	[thread overview]
Message-ID: <4BB2F7A0.6020702@viscovery.net> (raw)
In-Reply-To: <2cfc40321003300834w59532e58m13d42acce4f2c5ce@mail.gmail.com>

Am 3/30/2010 17:34, schrieb Jon Seymour:
> This variant of the patch uses git diff -c instead of git diff HEAD,
> at Johannes Sixt's suggestion.
> 
> The diff displayed in case of a merge conflict now shows the
> differences between the merge result and each of the local and remote
> heads and thus now also allows the user to assess the consequences of
> "Use Remote Version" by showing how the merge result affects the state
> of the local branch.
> 
> I have avoided using gmail client to forward this version of  patch
> because of documented word-wrapping issues, so hopefully this will
> apply cleanly.
> 
> [PATCH v3 1/2] git-gui: Introduce is_unmerged global variable to
> encapsulate its derivation.
> [PATCH v3 2/2] git-gui: change to display the combined diff in the
> case of conflicts.

I looked at the result, but it does not convince me. In my case, I have a
large file that has many changes between the "maint" and "master"
branches. Whenever there are conflicts after merging "maint" to "master",
I see all these changes, and really they *are* uninteresting.

But I, too, think that to offer "Use local version" and "Use remote
version" is *very* dangerous in a modify/modify conflict, particularly to
new-comers. I have only ever found these commands useful in the case of
modify/delete conflicts (and they are actually very handy in this case).

Even when the user sees all changes and can make a decision whether "Use
local" or "remote version" is really wanted, it is not at all obvious
which of the changes shown belong the "local" and which to "remote".

Therefore, I suggest to keep the original --cc display, but do not offer
"Use local version" and "Use remote version" when there is a modify/modify
conflict. The user is already offered "Run mergetool", and it is the safe
option besides editing the file.

-- Hannes

  reply	other threads:[~2010-03-31  7:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-30 15:34 [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts Jon Seymour
2010-03-31  7:20 ` Johannes Sixt [this message]
2010-03-31 11:12   ` Jon Seymour
2010-03-31 11:39     ` Johannes Sixt
2010-03-31 11:50       ` Jon Seymour
2010-03-31 12:23       ` Jon Seymour
2010-03-31 13:51         ` Johannes Sixt
2010-03-31 19:52           ` Jon Seymour
2010-04-02  8:37             ` Johannes Sixt
2010-04-04  6:44               ` Jon Seymour

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=4BB2F7A0.6020702@viscovery.net \
    --to=j.sixt@viscovery.net \
    --cc=git@vger.kernel.org \
    --cc=jon.seymour@gmail.com \
    --cc=spearce@spearce.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.