Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 2, 2010 at 7:37 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]