From: Jon Seymour <jon.seymour@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: git gui: merge conflict display is misleading since it hides non-conflicting remote hunks
Date: Sat, 27 Mar 2010 13:20:42 +1100 [thread overview]
Message-ID: <2cfc40321003261920k5b649eeeybeb84e1dbcb7787@mail.gmail.com> (raw)
In v1.6.6.1 of git (cygwin build), git gui has behaviour that I
believe is misleading in the presence of merge conflicts.
In the case in point the file being merged had diverged from the base
in both the local and remote repos.
The main hunks in each change merged cleanly, but there was a trivial
conflict on one line.
In GIT gui this was rendered as:
<<<<<<< HEAD
+import someclass;
=======
>>>>>>> remote
GIT GUI did not render the the interesting hunk from the remote that
merged cleanly.
As a result, the user thinks that the only conflict is the import
statement, and elects to resolve the commit in favour of the local
commit. This is the wrong thing to do because the remote hunk is then
lost to the history.
On the other hand, if the user manually resolves the conflict with an
editor and then rescans, the resolution of the conflict is shown, but
the remote hunk is not shown. Only if the user then adds the resolved
file to the index, does the remote hunk display in GIT GUI.
In my view, the current behaviour of git gui when displaying merge
conflicts is misleading because the display falsely leads the user
into the mistaken believing that the only change in the remote is the
conflict when, in fact, this is not true.
Is there any good reason why GIT gui can't show the full diff between
the working tree file and the current HEAD?
jon.
reply other threads:[~2010-03-27 2:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=2cfc40321003261920k5b649eeeybeb84e1dbcb7787@mail.gmail.com \
--to=jon.seymour@gmail.com \
--cc=git@vger.kernel.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).