From: Jon Seymour <jon.seymour@gmail.com>
To: Johannes Sixt <j.sixt@viscovery.net>
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 23:50:02 +1200 [thread overview]
Message-ID: <l2z2cfc40321003310450p51363facu1142c665512d6825@mail.gmail.com> (raw)
In-Reply-To: <4BB3346C.7070700@viscovery.net>
On Wed, Mar 31, 2010 at 11:39 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 3/31/2010 13:12, schrieb Jon Seymour:
>>> 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.
>>>
>>
>> I think you may have missed the point of my patch.
>>
>> The successfully merged lines may be uninteresting from the point of
>> deciding what I should *do* but they
>> are highly relevant to the question of what I really, really should *not* do.
>
> How would you decide that if you cannot read the information that is
> presented to you?
>
> Can you tell without thinking for 10 seconds which of these two changes is
> lost if you choose "Use local version"?
>
> @@@ ... @@@
> x
> +foo
> y
> @@@ ... @@@
> a
> - bar
> b
>
> Oh, it's easy for the conflicted part of the diff, which you'll see
> elsewhere as well:
>
> @@@ ... @@@
> r
> ++<<<<<<< HEAD
> +foo
> ++=======
> + bar
> ++>>>>>>> some-branch
> s
>
> Do not forget that in a case (like mine) where the non-condensed diff is
> actually huge, the conflict markers would no exactly be easy to find in
> the diff.
But that's exactly the point - not to make the choice easy, but to
make it obvious that the choice is *not easy*.
The problem is that as it stands the user things the only choice is
between choosing "foo" and choosing "bar".
> ++<<<<<<< HEAD
> +foo
> ++=======
> + bar
> ++>>>>>>> some-branch
This is a false choice but it is not obviously so.
The point of using diff -c is *precisely* to help the user understand
that it isn't a choice between foo and bar, but a choice
between losing all the changes that came with foo and all the changes
that came with bar.
> And therefore I suggest to disable these options.
>
I agree that this would be a better solution than leaving the behaviour as is.
> Which are those very simplest cases that you are referring to? If you mean
> modify/delete conflicts, then I indeed would like to keep the options for
> them.
The simplest case is when the presented diff presents the *whole*
difference between the local and remote branches.
As it stands, the gui can mislead the user into believing that the
presented diff is the whole difference and that their only
choice is between foo and bar.
Sure, users who have been bitten by this misapprehension will learn,
but it is hard lesson to learn.
>
> That said, your earlier patch that presented the diff against HEAD was not
> bad after all.
I prefer the -c version - not because the output is easy to
understand, but precisely because it gives pause.
jon.
next prev parent reply other threads:[~2010-03-31 11:50 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
2010-03-31 11:12 ` Jon Seymour
2010-03-31 11:39 ` Johannes Sixt
2010-03-31 11:50 ` Jon Seymour [this message]
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=l2z2cfc40321003310450p51363facu1142c665512d6825@mail.gmail.com \
--to=jon.seymour@gmail.com \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--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 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).