git.vger.kernel.org archive mirror
 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 13:39:24 +0200	[thread overview]
Message-ID: <4BB3346C.7070700@viscovery.net> (raw)
In-Reply-To: <k2p2cfc40321003310412hf4c6d642n4349af3f644829ff@mail.gmail.com>

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.

> If there are 100 successfully merged lines from each side of the merge
> but only 2 conflicting lines, should I
> 
> a) pick the remote branch
> b) pick the local branch
> c) manually edit the conflicting line (or use a merge tool)
> 
> The point of my patch it to make it much more likely that you will pick c).

And I was saying almost the same, namely that it should not only be "much
more likely" to pick c, but to *always* pick c (by making it the only
option available).

> In the current state, the GUI doesn't make it clear that either a) or
> b) is almost certainly a huge mistake.

And therefore I suggest to disable these options.

> Now, you could disable Use Remote and Use Local for all but the very
> simplest cases - but you don't need it for these
> cases. Hell, ed would do for these.

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.

That said, your earlier patch that presented the diff against HEAD was not
bad after all.

-- Hannes

  reply	other threads:[~2010-03-31 11:39 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 [this message]
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=4BB3346C.7070700@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 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).