From: Jon Seymour <jon.seymour@gmail.com>
To: spearce@spearce.org, Johannes Sixt <j.sixt@viscovery.net>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.
Date: Sun, 4 Apr 2010 16:44:57 +1000 [thread overview]
Message-ID: <o2m2cfc40321004032344of94fa946je6c1865cffccd69@mail.gmail.com> (raw)
In-Reply-To: <4BB5ACD3.10307@viscovery.net>
On Fri, Apr 2, 2010 at 7:37 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 31.03.2010 21:52, schrieb Jon Seymour:
>>
>> I agree that removing the options is better than preserving the
>> current behaviour,
>
> So, we are in agreement in this. Suppose we do remove them. What remains
> that is dangerous?
Stage to commit is still somewhat dangerous if the current "diff"
output is displayed because all the successfully staged changes
already in the index that will be purged by the "Stage to commit"
action will still not be visible until after the action is taken -
hence the original suggestion to use the "diff HEAD" output.
>
> The user has no option to accidentally revert changes that are not displayed
> even if the current diff --cc remains. The user is forced to run mergetool
> or to go to the editor.
>
> It is now an orthogonal matter whether diff --cc is helpful. Here I do agree
> somewhat that diff against HEAD is more helpful than the current diff --cc.
I am not sure the issues are completely orthogonal since I would still
argue that in the case the "Use Local/Use Remote" actions are
preserved, the diff -c output is the only output that provides enough
information to inform the user of the likely consequences of taking
each action. [ rationale: diff HEAD allows the consequences of Use
Local to be assessed, but does not allow the consequences of Use
Remote to be adequately assessed. ] That said, I agree that
the "diff HEAD" output is still better than the current "diff" output
in this situation since it does at least tell you want "Stage to
commit" will do with respect to the current HEAD (if not with respect
to successfully staged changes in the index).
I agree in the case that the "Use Local/Remote" actions are removed
from the UI, then the only remaining action of consequence is "Stage
to commit" and that for this "diff HEAD" output is the most
appropriate output to use in order to evaluate the expected
consequences of taking that action.
Until such time as I see some indication that Shawn will accept a
"Remove Use ... actions" patch, I'll assume that he won't. I will
likely re-roll the existing patch so that the user can choose via
configuration the diff options to be used for merge conflicts so that
people who don't like "diff -c" output can configure it to use "diff
HEAD" output instead.
>
>> I would imagine that a change that proposed to remove the actions,
>> without an option to enable them, would encounter stiff resistance
>> from the list. However, perhaps the list can respond?
>
> Who knows? There was not a lot discussion when the feature was presented to
> the list, not even a word of excitement.
>
> http://thread.gmane.org/gmane.comp.version-control.git/94425/focus=94426
>
True. Perhaps I should submit a "git-gui: Remove Use Remote/Local
actions" patch just to generate some excitement?
Shawn: any thoughts on any of this?
jon.
> -- Hannes
>
prev parent reply other threads:[~2010-04-04 6:45 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
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 [this message]
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=o2m2cfc40321004032344of94fa946je6c1865cffccd69@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).